7
Network Working Group M. Rose
8
Request for Comments: 1227 Performance Systems International, Inc.
12
SNMP MUX Protocol and MIB
16
This memo suggests a mechanism by which a user process may associate
17
itself with the local SNMP agent on a host, in order to implement
18
portions of the MIB. This mechanism would be local to the host.
20
This is an Experimental Protocol for the Internet community.
21
Discussion and suggestions for improvement are requested. Please
22
refer to the current edition of the "IAB Official Protocol Standards"
23
for the standardization state and status of this protocol.
24
Distribution of this memo is unlimited.
28
1. Introduction .......................................... 1
29
2. Architecture .......................................... 2
30
3. Protocol .............................................. 3
31
3.1 Tricky Things ........................................ 3
32
3.1.1 Registration ....................................... 4
33
3.1.2 Removing Registration .............................. 4
34
3.1.3 Atomic Sets ........................................ 4
35
3.1.4 Variables in Requests .............................. 5
36
3.1.5 Request-ID ......................................... 5
37
3.1.6 The powerful get-next operator ..................... 5
38
3.2 Protocol Data Units .................................. 6
39
3.3 Mappings on Transport Service ........................ 8
40
3.3.1 Mapping onto the TCP ............................... 8
41
4. MIB for the SMUX ...................................... 9
42
5. Acknowledgements ...................................... 12
43
6. References ............................................ 12
44
7. Security Considerations................................ 13
45
8. Author's Address....................................... 13
49
On typical kernel/user systems, an agent speaking the SNMP [1] is
50
often implemented as a user-process, that reads kernel variables in
51
order to realize the Internet-standard MIB [2]. This approach works
52
fine as long as all of the information needed by the SNMP agent
53
resides in either the kernel or in stable storage (i.e., files).
54
However, when other user-processes are employed to implement other
60
RFC 1227 SMUX May 1991
63
network services, such as routing protocols, communication between
64
the SNMP agent and other processes is problematic.
66
In order to solve this problem, a new protocol, the SNMP multiplexing
67
(SMUX) protocol is introduced. When a user-process, termed a SMUX
68
peer, wishes to export a MIB module, it initiates a SMUX association
69
to the local SNMP agent, registers itself, and (later) fields
70
management operations for objects in the MIB module.
72
Carrying this approach to its fullest, it is possible to generalize
73
the SNMP agent so that it knows about only the SNMP group of the
74
Internet-standard MIB. All other portions of the Internet-standard
75
MIB can be implemented by another process. This is quite useful, for
76
example, when a computer manufacturer wishes to provide SNMP access
77
for its operating system in binary form.
79
In addition to defining the SMUX protocol, this document defines a
80
MIB for the SMUX. Obviously, this MIB module must also be
81
implemented in the local SNMP agent.
85
There are two approaches that can be taken when trying to integrate
86
arbitrary MIB modules with the SNMP agent: request-response and
89
The request-response model simply propagates the SNMP requests
90
received by the SNMP agent to the user process which exported the MIB
91
module. The SMUX peer then performs the operation and returns a
92
response. In turn, the SNMP agent propagates this response back to
93
the network management station. The request-response model is said
94
to be agent-driven since, after registration, the SNMP agent
95
initiates all transactions.
97
The cache-ahead model requires that the SMUX peer, after
98
registration, periodically updates the SNMP agent with the subtree
99
for the MIB module which has been registered. The SNMP agent, upon
100
receiving an SNMP request for information retrieval, locally performs
101
the operation, and returns a response to the network management
102
station. (SNMP set requests are given immediately to the SMUX peer.)
103
The cache-ahead model is said to be peer-driven since, after
104
registration, the SMUX peer initiates all transactions.
106
There are advantages and disadvantages to both approaches. As such,
107
the architecture envisioned supports both models in the following
108
fashion: the protocol between the SNMP agent and the SMUX peer is
109
based on the request-response model. However, the SMUX peer, may
110
itself be a user-process which employs the cache-ahead model with
116
RFC 1227 SMUX May 1991
119
other user-processes.
121
Obviously, the SMUX peer which employs the cache-ahead model acts as
122
a "firewall" for those user-processes which actually implement the
123
managed objects in the given MIB module.
125
Note that this document describes only the SMUX protocol, for the
126
request-response model. Each SMUX peer is free to define a cache-
127
ahead protocol specific for the application at hand.
131
The SMUX protocol is simple: the SNMP agent listens for incoming
132
connections. Upon establishing a connection, the SMUX peer issues an
133
OpenPDU to initialize the SMUX association. If the SNMP agent
134
declines the association, it issues a closePDU and closes the
135
connection. If the SNMP agent accepts the association, no response
136
is issued by the SNMP agent.
138
For each subtree defined in a MIB module that the SMUX peer wishes to
139
register (or unregister), the SMUX peer issues a RReqPDU. When the
140
SNMP agent receives such a PDU, it issues a corresponding RRspPDU.
141
The SNMP agent returns RRspPDUs in the same order as the RReqPDUs
144
When the SMUX peer wishes to issue a trap, it issues an SNMP Trap-
145
PDU. When the SNMP agent receives such a PDU, it propagates this to
146
the network management stations that it is configured to send traps
149
When the SNMP agent receives an SNMP GetRequest-PDU, GetNextRequest-
150
PDU, or SetRequest-PDU which includes one or more variable-bindings
151
within a subtree registered by a SMUX peer, the SNMP agent sends an
152
equivalent SNMP PDU containing only those variables within the
153
subtree registered by that SMUX peer. When the SMUX peer receives
154
such a PDU, it applies the indicated operation and issues a
155
corresponding SNMP GetResponse-PDU. The SNMP agent then correlates
156
this result and propagates the resulting GetResponse-PDU to the
157
network management station.
159
When either the SNMP agent or the SMUX peer wishes to release the
160
SMUX association, the ClosePDU is issued, the connection is closed,
161
and all subtree registrations for that association are released.
165
Although straight-forward, there are a few nuances.
172
RFC 1227 SMUX May 1991
177
Associated with each registration is an integer priority, from 0 to
178
(2^31)-1. The lower the value, the higher the priority.
180
Multiple SMUX peers may register the same subtree. However, they
181
must do so at different priorities (i.e., a subtree and a priority
182
uniquely identifies a SMUX peer). As such, if a SMUX peer wishes to
183
register a subtree at a priority which is already taken, the SNMP
184
agent repeatedly increments the integer value until an unused
187
When registering a subtree, the special priority -1 may be used,
188
which selects the highest available priority.
190
Of course, the SNMP agent may select an arbitrarily worse priority
191
for a SMUX peer, based on local (configuration) information.
193
Note that when a subtree is registered, the SMUX peer with the
194
highest registration priority is exclusively consulted for all
195
operations on that subtree. Further note that SNMP agents must
196
enforce the "subtree mounting effect", which hides the registrations
197
by other SMUX peers of objects within the subtree. For example, if a
198
SMUX peer registered "sysDescr", and later another SMUX peer
199
registered "system" (which scopes "sysDescr"), then all requests for
200
"sysDescr" would be given to the latter SMUX peer.
202
An SNMP agent should disallow any attempt to register above, at, or
203
below, the SNMP and SMUX subtrees of the MIB. Other subtrees may be
204
disallowed as an implementation-specific option.
206
3.1.2. Removing Registration
208
A SMUX peer may remove registrations for only those subtrees which it
209
has registered. If the priority given in the RReqPDU is -1, then the
210
registration of highest priority is selected for deletion.
211
Otherwise, only that registration with the precise priority is
216
A simple two-phase commit protocol is used between the SNMP agent and
217
the SMUX peers. When an SNMP SetRequest-PDU is received, the SNMP
218
agent determines which SMUX peers will participate in the
219
transaction. For each of these peers, at least one SNMP SetRequest-
220
PDU is sent, with only those variables of interest to that peer.
222
Each SMUX peer must either accept or refuse the set operation,
228
RFC 1227 SMUX May 1991
231
without actually performing the operation. If the peer opts to
232
accept, it sends back an SNMP GetResponse-PDU with an error-status of
233
noError(0); otherwise, if the peer refuses to perform the operation,
234
then an SNMP GetResponse-PDU is returned with a non-zero error-
237
The SNMP agent examines all of the responses. If at least one SMUX
238
peer refused the operation, then a SMUX SOutPDU is sent to each SMUX
239
peer, with value rollback, telling the SMUX peer to discard any
240
knowledge of the requested operation.
242
Otherwise if all SMUX peers accepted the operation, then a SMUX
243
SOutPDU is sent to each SMUX peer, with value commit, telling the
244
SMUX peer to perform the operation.
246
In either case, the SMUX peer does not generate a response to the
249
3.1.4. Variables in Requests
251
When constructing an SNMP GetRequest-PDU or GetNextRequest-PDU for a
252
SMUX peer, the SNMP agent may send one, or more than one variable in
253
a single request. In all cases, the SNMP agent should process each
254
variable sequentially, and block accordingly when a SMUX peer is
259
When the SNMP agent constructs an SNMP GetRequest-PDU,
260
GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the
261
request_id field of the SNMP takes a special meaning: if an SNMP
262
agent generates multiple PDUs for a SMUX peer, upon receipt of a
263
single PDU from the network management station, then the request_id
264
field of the PDUs sent to the SMUX peer must take the same value
265
(which need bear no relationship to the value of the request_id field
266
of the PDU originally received by the SNMP agent.)
268
3.1.6. The powerful get-next operator
270
Each SMUX peer acts as though it contains the entire MIB when
271
processing a SNMP GetNext-PDU from the SNMP agent. This means that
272
the SNMP agent must check each variable returned in the SNMP
273
GetResponse-PDU generated by the SMUX peer to ensure that each
274
variable is still within the same registered subtree as caused the
275
SNMP GetNext-PDU to be sent to that peer. For each variable which is
276
not, the SNMP agent must include it in a SNMP GetNext-PDU to the peer
277
for the succeeding registered subtree, until responses are available
278
for all variables within their expected registered subtree.
284
RFC 1227 SMUX May 1991
287
3.2. Protocol Data Units
289
The SMUX protocol data units are defined using Abstract Syntax
290
Notation One (ASN.1) [3]:
292
SMUX DEFINITIONS ::= BEGIN
295
DisplayString, ObjectName
302
-- tags for SMUX-specific PDUs are application-wide to
303
-- avoid conflict with tags for current (and future)
308
open -- SMUX peer uses
309
OpenPDU, -- immediately after TCP open
311
close -- either uses immediately before TCP close
314
registerRequest -- SMUX peer uses
317
registerResponse -- SNMP agent uses
320
PDUs, -- note that roles are reversed:
321
-- SNMP agent does get/get-next/set
322
-- SMUX peer does get-response/trap
324
commitOrRollback -- SNMP agent uses
330
-- currently only simple authentication
340
RFC 1227 SMUX May 1991
347
[APPLICATION 0] IMPLICIT
349
version -- of SMUX protocol
354
identity -- of SMUX peer, authoritative
357
description -- of SMUX peer, implementation-specific
360
password -- zero length indicates no authentication
368
[APPLICATION 1] IMPLICIT
371
unsupportedVersion(1),
375
authenticationFailure(5)
382
[APPLICATION 2] IMPLICIT
387
priority -- the lower the better, "-1" means default
388
INTEGER (-1..2147483647),
396
RFC 1227 SMUX May 1991
400
delete(0), -- remove registration
401
readOnly(1), -- add registration, objects are RO
402
readWrite(2) -- .., objects are RW
407
[APPLICATION 3] IMPLICIT
411
-- on success the non-negative priority is returned
415
[APPLICATION 4] IMPLICIT
424
3.3. Mappings on Transport Service
426
The SMUX protocol may be mapped onto any CO-mode transport service.
427
At present, only one such mapping is defined.
429
3.3.1. Mapping onto the TCP
431
When using the TCP to provide the transport-backing for the SMUX
432
protocol, the SNMP agent listens on TCP port 199.
434
Each SMUX PDU is serialized using the Basic Encoding Rules [4] and
435
sent on the TCP. As ASN.1 objects are self-delimiting when encoding
436
using the BER, no packetization protocol is required.
452
RFC 1227 SMUX May 1991
457
The MIB objects for the SMUX are implemented by the local SNMP agent:
459
SMUX-MIB DEFINITIONS ::= BEGIN
467
unix OBJECT IDENTIFIER ::= { enterprises 4 }
469
smux OBJECT IDENTIFIER ::= { unix 4 }
471
smuxPeerTable OBJECT-TYPE
472
SYNTAX SEQUENCE OF SmuxPeerEntry
473
ACCESS not-accessible
476
"The SMUX peer table."
479
smuxPeerEntry OBJECT-TYPE
481
ACCESS not-accessible
484
"An entry in the SMUX peer table."
486
::= { smuxPeerTable 1}
500
smuxPindex OBJECT-TYPE
508
RFC 1227 SMUX May 1991
513
"An index which uniquely identifies a SMUX peer."
514
::= { smuxPeerEntry 1 }
516
smuxPidentity OBJECT-TYPE
517
SYNTAX OBJECT IDENTIFIER
521
"The authoritative designation for a SMUX peer."
522
::= { smuxPeerEntry 2 }
524
smuxPdescription OBJECT-TYPE
525
SYNTAX DisplayString (SIZE (0..255))
529
"A human-readable description of a SMUX peer."
530
::= { smuxPeerEntry 3 }
532
smuxPstatus OBJECT-TYPE
533
SYNTAX INTEGER { valid(1), invalid(2), connecting(3) }
537
"The type of SMUX peer.
539
Setting this object to the value invalid(2) has
540
the effect of invaliding the corresponding entry
541
in the smuxPeerTable. It is an implementation-
542
specific matter as to whether the agent removes an
543
invalidated entry from the table. Accordingly,
544
management stations must be prepared to receive
545
tabular information from agents that correspond to
546
entries not currently in use. Proper
547
interpretation of such entries requires
548
examination of the relative smuxPstatus object."
549
::= { smuxPeerEntry 4 }
551
smuxTreeTable OBJECT-TYPE
552
SYNTAX SEQUENCE OF SmuxTreeEntry
553
ACCESS not-accessible
556
"The SMUX tree table."
564
RFC 1227 SMUX May 1991
567
smuxTreeEntry OBJECT-TYPE
569
ACCESS not-accessible
572
"An entry in the SMUX tree table."
573
INDEX { smuxTsubtree, smuxTpriority }
574
::= { smuxTreeTable 1}
588
smuxTsubtree OBJECT-TYPE
589
SYNTAX OBJECT IDENTIFIER
593
"The MIB subtree being exported by a SMUX peer."
594
::= { smuxTreeEntry 1 }
596
smuxTpriority OBJECT-TYPE
597
SYNTAX INTEGER (0..'07fffffff'h)
601
"The SMUX peer's priority when exporting the MIB
603
::= { smuxTreeEntry 2 }
605
smuxTindex OBJECT-TYPE
610
"The SMUX peer's identity."
611
::= { smuxTreeEntry 3 }
613
smuxTstatus OBJECT-TYPE
614
SYNTAX INTEGER { valid(1), invalid(2) }
620
RFC 1227 SMUX May 1991
626
"The type of SMUX tree.
628
Setting this object to the value invalid(2) has
629
the effect of invaliding the corresponding entry
630
in the smuxTreeTable. It is an implementation-
631
specific matter as to whether the agent removes an
632
invalidated entry from the table. Accordingly,
633
management stations must be prepared to receive
634
tabular information from agents that correspond to
635
entries not currently in use. Proper
636
interpretation of such entries requires
637
examination of the relative smuxTstatus object."
638
::= { smuxTreeEntry 4 }
644
SMUX was designed one afternoon by these people:
646
Jeffrey S. Case, UTK-CS
647
James R. Davin, MIT-LCS
649
Jeffrey C. Honig, Cornell
650
Louie A. Mamakos, UMD
651
Michael G. Petry, UMD
653
Marshall T. Rose, PSI
657
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
658
Network Management Protocol", RFC 1157, SNMP Research,
659
Performance Systems International, Performance Systems
660
International, MIT Laboratory for Computer Science, May 1990.
662
[2] McCloghrie K., and M. Rose, "Management Information Base for
663
Network Management of TCP/IP-based Internets", RFC 1156,
664
Performance Systems International and Hughes LAN Systems, May
667
[3] Information processing systems - Open Systems Interconnection -
668
Specification of Abstract Syntax Notation One (ASN.1),
669
International Organization for Standardization, International
670
Standard 8824, December 1987.
676
RFC 1227 SMUX May 1991
679
[4] Information processing systems - Open Systems Interconnection -
680
Specification of Basic Encoding Rules for Abstract Notation One
681
(ASN.1), International Organization for Standardization,
682
International Standard 8825, December 1987.
684
[5] Rose, M., and K. McCloghrie, "Structure and Identification of
685
Management Information for TCP/IP-based Internets", RFC 1155,
686
Performance Systems International and Hughes LAN Systems, May
689
7. Security Considerations
691
Security issues are not discussed in this memo.
696
Performance Systems International, Inc.
697
5201 Great America Parkway
699
Santa Clara, CA 95054
701
Phone: +1 408 562 6222
b'\\ No newline at end of file'
added
removed
doc/rfc/rfc1227.txt
