RFC relevance of register

As per Relevance of the word register, 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