As per Relevance of the word registration, we have this rfc below:
Network Working Group M.
Request for Comments: 1227 Performance Systems International, Inc
May 1991
SNMP MUX Protocol and
Status of this
This memo suggests a mechanism by which a user process may
itself with the local SNMP agent on a host, in order to
portions of the MIB. This mechanism would be local to the host
This is an Experimental Protocol for the Internet community
Discussion and suggestions for improvement are requested.
refer to the current edition of the "IAB Official Protocol Standards
for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Introduction .......................................... 1
2. Architecture .......................................... 2
3. Protocol .............................................. 3
3.1 Tricky Things ........................................ 3
3.1.1 Registration ....................................... 4
3.1.2 Removing Registration .............................. 4
3.1.3 Atomic Sets ........................................ 4
3.1.4 Variables in Requests .............................. 5
3.1.5 Request-ID ......................................... 5
3.1.6 The powerful get-next operator ..................... 5
3.2 Protocol Data Units .................................. 6
3.3 Mappings on Transport Service ........................ 8
3.3.1 Mapping onto the TCP ............................... 8
4. MIB for the SMUX ...................................... 9
5. Acknowledgements ...................................... 12
6. References ............................................ 12
7. Security Considerations................................ 13
8. Author's Address....................................... 13
1.
On typical kernel/user systems, an agent speaking the SNMP [1]
often implemented as a user-process, that reads kernel variables
order to realize the Internet-standard MIB [2]. This approach
fine as long as all of the information needed by the SNMP
resides in either the kernel or in stable storage (i.e., files).
However, when other user-processes are employed to implement
Rose [Page 1]
RFC 1227 SMUX May 1991
network services, such as routing protocols, communication
the SNMP agent and other processes is problematic
In order to solve this problem, a new protocol, the SNMP
(SMUX) protocol is introduced. When a user-process, termed a
peer, wishes to export a MIB module, it initiates a SMUX
to the local SNMP agent, registers itself, and (later)
management operations for objects in the MIB module
Carrying this approach to its fullest, it is possible to
the SNMP agent so that it knows about only the SNMP group of
Internet-standard MIB. All other portions of the Internet-
MIB can be implemented by another process. This is quite useful,
example, when a computer manufacturer wishes to provide SNMP
for its operating system in binary form
In addition to defining the SMUX protocol, this document defines
MIB for the SMUX. Obviously, this MIB module must also
implemented in the local SNMP agent
2.
There are two approaches that can be taken when trying to
arbitrary MIB modules with the SNMP agent: request-response
cache-ahead
The request-response model simply propagates the SNMP
received by the SNMP agent to the user process which exported the
module. The SMUX peer then performs the operation and returns
response. In turn, the SNMP agent propagates this response back
the network management station. The request-response model is
to be agent-driven since, after registration, the SNMP
initiates all transactions
The cache-ahead model requires that the SMUX peer,
registration, periodically updates the SNMP agent with the
for the MIB module which has been registered. The SNMP agent,
receiving an SNMP request for information retrieval, locally
the operation, and returns a response to the network
station. (SNMP set requests are given immediately to the SMUX peer.)
The cache-ahead model is said to be peer-driven since,
registration, the SMUX peer initiates all transactions
There are advantages and disadvantages to both approaches. As such
the architecture envisioned supports both models in the
fashion: the protocol between the SNMP agent and the SMUX peer
based on the request-response model. However, the SMUX peer,
itself be a user-process which employs the cache-ahead model
Rose [Page 2]
RFC 1227 SMUX May 1991
other user-processes
Obviously, the SMUX peer which employs the cache-ahead model acts
a "firewall" for those user-processes which actually implement
managed objects in the given MIB module
Note that this document describes only the SMUX protocol, for
request-response model. Each SMUX peer is free to define a cache
ahead protocol specific for the application at hand
3.
The SMUX protocol is simple: the SNMP agent listens for
connections. Upon establishing a connection, the SMUX peer issues
OpenPDU to initialize the SMUX association. If the SNMP
declines the association, it issues a closePDU and closes
connection. If the SNMP agent accepts the association, no
is issued by the SNMP agent
For each subtree defined in a MIB module that the SMUX peer wishes
register (or unregister), the SMUX peer issues a RReqPDU. When
SNMP agent receives such a PDU, it issues a corresponding RRspPDU
The SNMP agent returns RRspPDUs in the same order as the
were received
When the SMUX peer wishes to issue a trap, it issues an SNMP Trap
PDU. When the SNMP agent receives such a PDU, it propagates this
the network management stations that it is configured to send
to
When the SNMP agent receives an SNMP GetRequest-PDU, GetNextRequest
PDU, or SetRequest-PDU which includes one or more variable-
within a subtree registered by a SMUX peer, the SNMP agent sends
equivalent SNMP PDU containing only those variables within
subtree registered by that SMUX peer. When the SMUX peer
such a PDU, it applies the indicated operation and issues
corresponding SNMP GetResponse-PDU. The SNMP agent then
this result and propagates the resulting GetResponse-PDU to
network management station
When either the SNMP agent or the SMUX peer wishes to release
SMUX association, the ClosePDU is issued, the connection is closed
and all subtree registrations for that association are released
3.1. Tricky
Although straight-forward, there are a few nuances
Rose [Page 3]
RFC 1227 SMUX May 1991
3.1.1.
Associated with each registration is an integer priority, from 0
(2^31)-1. The lower the value, the higher the priority
Multiple SMUX peers may register the same subtree. However,
must do so at different priorities (i.e., a subtree and a
uniquely identifies a SMUX peer). As such, if a SMUX peer wishes
register a subtree at a priority which is already taken, the
agent repeatedly increments the integer value until an
priority is found
When registering a subtree, the special priority -1 may be used
which selects the highest available priority
Of course, the SNMP agent may select an arbitrarily worse
for a SMUX peer, based on local (configuration) information
Note that when a subtree is registered, the SMUX peer with
highest registration priority is exclusively consulted for
operations on that subtree. Further note that SNMP agents
enforce the "subtree mounting effect", which hides the
by other SMUX peers of objects within the subtree. For example, if
SMUX peer registered "sysDescr", and later another SMUX
registered "system" (which scopes "sysDescr"), then all requests
"sysDescr" would be given to the latter SMUX peer
An SNMP agent should disallow any attempt to register above, at,
below, the SNMP and SMUX subtrees of the MIB. Other subtrees may
disallowed as an implementation-specific option
3.1.2. Removing
A SMUX peer may remove registrations for only those subtrees which
has registered. If the priority given in the RReqPDU is -1, then
registration of highest priority is selected for deletion
Otherwise, only that registration with the precise priority
selected
3.1.3. Atomic
A simple two-phase commit protocol is used between the SNMP agent
the SMUX peers. When an SNMP SetRequest-PDU is received, the
agent determines which SMUX peers will participate in
transaction. For each of these peers, at least one SNMP SetRequest
PDU is sent, with only those variables of interest to that peer
Each SMUX peer must either accept or refuse the set operation
Rose [Page 4]
RFC 1227 SMUX May 1991
without actually performing the operation. If the peer opts
accept, it sends back an SNMP GetResponse-PDU with an error-status
noError(0); otherwise, if the peer refuses to perform the operation
then an SNMP GetResponse-PDU is returned with a non-zero error
status
The SNMP agent examines all of the responses. If at least one
peer refused the operation, then a SMUX SOutPDU is sent to each
peer, with value rollback, telling the SMUX peer to discard
knowledge of the requested operation
Otherwise if all SMUX peers accepted the operation, then a
SOutPDU is sent to each SMUX peer, with value commit, telling
SMUX peer to perform the operation
In either case, the SMUX peer does not generate a response to
SMUX SOutPDU
3.1.4. Variables in
When constructing an SNMP GetRequest-PDU or GetNextRequest-PDU for
SMUX peer, the SNMP agent may send one, or more than one variable
a single request. In all cases, the SNMP agent should process
variable sequentially, and block accordingly when a SMUX peer
contacted
3.1.5. Request-
When the SNMP agent constructs an SNMP GetRequest-PDU
GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer,
request_id field of the SNMP takes a special meaning: if an
agent generates multiple PDUs for a SMUX peer, upon receipt of
single PDU from the network management station, then the request_
field of the PDUs sent to the SMUX peer must take the same
(which need bear no relationship to the value of the request_id
of the PDU originally received by the SNMP agent.)
3.1.6. The powerful get-next
Each SMUX peer acts as though it contains the entire MIB
processing a SNMP GetNext-PDU from the SNMP agent. This means
the SNMP agent must check each variable returned in the
GetResponse-PDU generated by the SMUX peer to ensure that
variable is still within the same registered subtree as caused
SNMP GetNext-PDU to be sent to that peer. For each variable which
not, the SNMP agent must include it in a SNMP GetNext-PDU to the
for the succeeding registered subtree, until responses are
for all variables within their expected registered subtree
Rose [Page 5]
RFC 1227 SMUX May 1991
3.2. Protocol Data
The SMUX protocol data units are defined using Abstract
Notation One (ASN.1) [3]:
SMUX DEFINITIONS ::=
DisplayString,
FROM RFC1155-
FROM RFC1157-SNMP
-- tags for SMUX-specific PDUs are application-wide
-- avoid conflict with tags for current (and future
-- SNMP-generic
SMUX-PDUs ::=
CHOICE {
open -- SMUX peer
OpenPDU, -- immediately after TCP
close -- either uses immediately before TCP
ClosePDU
registerRequest -- SMUX peer
RReqPDU
registerResponse -- SNMP agent
RRspPDU
PDUs, -- note that roles are reversed
-- SNMP agent does get/get-next/
-- SMUX peer does get-response/
commitOrRollback -- SNMP agent
}
-- open
-- currently only simple
OpenPDU ::=
CHOICE {
Rose [Page 6]
RFC 1227 SMUX May 1991
}
SimpleOpen ::=
[APPLICATION 0]
SEQUENCE {
version -- of SMUX
INTEGER {
version-1(0)
},
identity -- of SMUX peer,
OBJECT IDENTIFIER
description -- of SMUX peer, implementation-
DisplayString
password -- zero length indicates no
OCTET
}
-- close
ClosePDU ::=
[APPLICATION 1]
INTEGER {
goingDown(0),
unsupportedVersion(1),
packetFormat(2),
protocolError(3),
internalError(4),
authenticationFailure(5)
}
-- insert
RReqPDU ::=
[APPLICATION 2]
SEQUENCE {
ObjectName
priority -- the lower the better, "-1" means
INTEGER (-1..2147483647),
Rose [Page 7]
RFC 1227 SMUX May 1991
INTEGER {
delete(0), -- remove
readOnly(1), -- add registration, objects are
readWrite(2) -- .., objects are
}
}
RRspPDU ::=
[APPLICATION 3]
INTEGER {
failure(-1)
-- on success the non-negative priority is
}
SOutPDU ::=
[APPLICATION 4]
INTEGER {
commit(0),
rollback(1)
}
3.3. Mappings on Transport
The SMUX protocol may be mapped onto any CO-mode transport service
At present, only one such mapping is defined
3.3.1. Mapping onto the
When using the TCP to provide the transport-backing for the
protocol, the SNMP agent listens on TCP port 199.
Each SMUX PDU is serialized using the Basic Encoding Rules [4]
sent on the TCP. As ASN.1 objects are self-delimiting when
using the BER, no packetization protocol is required
Rose [Page 8]
RFC 1227 SMUX May 1991
4. MIB for the
The MIB objects for the SMUX are implemented by the local SNMP agent
SMUX-MIB DEFINITIONS ::=
FROM RFC1155-
OBJECT-
FROM RFC1212;
unix OBJECT IDENTIFIER ::= { enterprises 4 }
smux OBJECT IDENTIFIER ::= { unix 4 }
smuxPeerTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"The SMUX peer table."
::= { smux 1 }
smuxPeerEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the SMUX peer table."
INDEX { smuxPindex }
::= { smuxPeerTable 1}
SmuxPeerEntry ::=
SEQUENCE {
INTEGER
OBJECT IDENTIFIER
DisplayString
}
smuxPindex OBJECT-
SYNTAX
ACCESS read-
Rose [Page 9]
RFC 1227 SMUX May 1991
STATUS
"An index which uniquely identifies a SMUX peer."
::= { smuxPeerEntry 1 }
smuxPidentity OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"The authoritative designation for a SMUX peer."
::= { smuxPeerEntry 2 }
smuxPdescription OBJECT-
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-
STATUS
"A human-readable description of a SMUX peer."
::= { smuxPeerEntry 3 }
smuxPstatus OBJECT-
SYNTAX INTEGER { valid(1), invalid(2), connecting(3) }
ACCESS read-
STATUS
"The type of SMUX peer
Setting this object to the value invalid(2)
the effect of invaliding the corresponding
in the smuxPeerTable. It is an implementation
specific matter as to whether the agent removes
invalidated entry from the table. Accordingly
management stations must be prepared to
tabular information from agents that correspond
entries not currently in use.
interpretation of such entries
examination of the relative smuxPstatus object."
::= { smuxPeerEntry 4 }
smuxTreeTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"The SMUX tree table."
::= { smux 2 }
Rose [Page 10]
RFC 1227 SMUX May 1991
smuxTreeEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry in the SMUX tree table."
INDEX { smuxTsubtree, smuxTpriority }
::= { smuxTreeTable 1}
SmuxTreeEntry ::=
SEQUENCE {
OBJECT IDENTIFIER
INTEGER
INTEGER
}
smuxTsubtree OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"The MIB subtree being exported by a SMUX peer."
::= { smuxTreeEntry 1 }
smuxTpriority OBJECT-
SYNTAX INTEGER (0..'07fffffff'h
ACCESS read-
STATUS
"The SMUX peer's priority when exporting the
subtree."
::= { smuxTreeEntry 2 }
smuxTindex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The SMUX peer's identity."
::= { smuxTreeEntry 3 }
smuxTstatus OBJECT-
SYNTAX INTEGER { valid(1), invalid(2) }
Rose [Page 11]
RFC 1227 SMUX May 1991
ACCESS read-
STATUS
"The type of SMUX tree
Setting this object to the value invalid(2)
the effect of invaliding the corresponding
in the smuxTreeTable. It is an implementation
specific matter as to whether the agent removes
invalidated entry from the table. Accordingly
management stations must be prepared to
tabular information from agents that correspond
entries not currently in use.
interpretation of such entries
examination of the relative smuxTstatus object."
::= { smuxTreeEntry 4 }
5.
SMUX was designed one afternoon by these people
Jeffrey S. Case, UTK-
James R. Davin, MIT-
Mark S. Fedor,
Jeffrey C. Honig,
Louie A. Mamakos,
Michael G. Petry,
Yakov Rekhter,
Marshall T. Rose,
6.
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[2] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based Internets", RFC 1156,
Performance Systems International and Hughes LAN Systems,
1990.
[3] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization,
Standard 8824, December 1987.
Rose [Page 12]
RFC 1227 SMUX May 1991
[4] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation
(ASN.1), International Organization for Standardization
International Standard 8825, December 1987.
[5] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International and Hughes LAN Systems,
1990.
7. Security
Security issues are not discussed in this memo
8. Author's
Marshall T.
Performance Systems International, Inc
5201 Great America
Suite 3106
Santa Clara, CA 95054
Phone: +1 408 562 6222
EMail: mrose@psi.
X.500: rose, psi,
Rose [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
