



          draft                        SMUX                February 1990


                            SNMP MUX Protocol and MIB

                             Mon Feb 19 17:36:27 1990


                                 Marshall T. Rose

                     Performance Systems International, Inc.
                                1935 Lake Port Way
                                 Reston,VA  22091

                                  MRose@PSI.COM






          1.  Status of this Memo

          This document defines a mechanism by which multiple UNIX
          daemons may communicate with the local SNMP agent on a host.
          This is a local mechanism.



























          M.T. Rose                                             [Page 1]





          draft                        SMUX                February 1990


          2.  Introduction

          On kernel/user systems such as BSD UNIX, an agent speaking the
          SNMP [1] is often implemented as a user-process, which reads
          kernel variables in order to realize the Internet-standard MIB
          [2].  This approach works fine as long as all of the
          information needed by the SNMP agent resides in either the
          kernel or in stable storage (i.e., files).  However, when
          other user-processes are employed to implement other network
          services, such as routing protocols, communication between the
          SNMP agent the and other processes is problematic.

          In order to solve this problem, a new protocol, the SNMP
          multiplexing (SMUX) protocol is introduced.  When a user-
          process, termed a SMUX peer, wishes to export a MIB module, it
          initiates a SMUX association to the local SNMP agent,
          registers itself, and (later) fields management operations for
          objects in the MIB module.

          Carrying this approach to its fullest.  It is possible to
          generalize the SNMP agent so that it knows about only the SNMP
          group of the Internet-standard MIB.  All other portions of the
          Internet-standard MIB can be implemented by another process.
          This is quite useful, for example, when a computer
          manufacturer wishes to provide SNMP access for its operating
          system in binary form.

          In addition to defining the SMUX protocol, this document
          defines a MIB for the SMUX.  Obviously, this MIB module must
          also be implemented in the local SNMP agent.




















          M.T. Rose                                             [Page 2]





          draft                        SMUX                February 1990


          3.  Architecture

          There are two approaches that can be taken when trying to
          integrate arbitrary MIB modules with the SNMP agent: request-
          response and cache-ahead.

          The request-response model simply propagates the SNMP requests
          received by the SNMP agent to the user process which exported
          the MIB module.  The SMUX peer then performs the operation and
          returns a response.  In turn, the SNMP agent propagates this
          response back to the network management station.  The
          request-response model is said to be agent-driven since, after
          registration, the SNMP agent initiates all transactions.

          The cache-ahead model requires that the SMUX peer, after
          registration, periodically update the SNMP agent with the
          subtree for the MIB module which has been registered.  The
          SNMP agent, upon receiving an SNMP request, locally performs
          the operation, and returns a response to the network
          management station.  The cache-ahead model is said to be
          peer-driven since, after 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
          following fashion: the protocol between the SNMP agent and the
          SMUX peer is based on the request-response model.  However,
          the SMUX peer, may itself be a user-process which employs the
          cache-ahead model with other user-processes.

          Obviously, the SMUX peer which employs the cache-ahead model
          acts as a "firewall" for those user-processes which actually
          implement the managed objects in the given MIB module.

          Note that this document describes only the SMUX protocol, for
          the request-response model.  Each SMUX peer is free to define
          a cache-ahead protocol specific for the application at hand.













          M.T. Rose                                             [Page 3]





          draft                        SMUX                February 1990


          4.  Protocol

          The SMUX protocol is simple: the SNMP agent listens for
          incoming connections.  Upon establishing a connection, the
          SMUX peer issues an OpenPDU to initialize the SMUX
          association.  If the SNMP agent declines the association, it
          issues an closePDU and closes the connection.  If the SNMP
          agent accepts the association, no response is issued by the
          SNMP agent.

          For each subtree defined in a MIB module that the SMUX peer
          wishes to register (or unregister), the SMUX peer issues a
          RReqPDU.  When the SNMP agent receives such a PDU, it issues a
          corresponding RRspPDU.  The SNMP agent returns RRspPDUs in the
          same order as the RReqPDUs 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 to the network management stations that it is
          configured to send traps to.

          When the SNMP agent receives an SNMP GetRequest-PDU,
          GetNextRequest-PDU, or SetRequest-PDU which includes one or
          more variable-bindings within a subtree registered by a SMUX
          peer, the SNMP agent sends an equivalent SNMP PDU containing
          only those variables within the subtree registered by that
          SMUX peer.  When the SMUX peer receives such a PDU, it applies
          the indicated operation and issues a corresponding SNMP
          GetResponse-PDU.  The SNMP agent then correlates this result
          and propagates the resulting GetResponse-PDU to the network
          management station.

          When either the SNMP agent or the SMUX peer wishes to release
          the SMUX association, the ClosePDU is issued and the
          connection is closed.


          4.1.  Tricky Things

          Although straight-forward, there are a few nuances.










          M.T. Rose                                             [Page 4]





          draft                        SMUX                February 1990


          4.1.1.  Registration

          Associated with each registration is an integer priority, from
          0 to (2^31)-1.  The lower the value, the higher the priority.

          Multiple SMUX peers may register the same subtree.  However,
          they must do so at different priorities (i.e., a subtree and a
          priority uniquely identifies a SMUX peer).  As such, if a SMUX
          peer wishes to register a subtree at a priority which is
          already taken, the SNMP agent repeatedly increments the
          integer value until an unused 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
          priority for a SMUX peer, based on local (configuration
          information.

          Note that when a subtree is registered, the SMUX peer with the
          highest registration priority is exclusively consulted for all
          operations on that subtree.  Further note that SNMP agents
          must enforce the "subtree mounting effect", which hides the
          registrations by other SMUX peers of objects within the
          subtree.  For example, if a SMUX peer registered "sysDescr",
          and later another SMUX peer registered "system", (which scopes
          "sysDescr"), then all requests for "sysDescr" would be given
          to the latter SMUX peer.

          An SNMP agent should disallow any attempt to register at or
          within the SNMP and SMUX subtrees of the MIB.  Other subtrees
          may be disallowed as an implementation-specific option.


          4.1.2.  Removing Registration

          A SMUX peer may remove registrations for only those subtrees
          which it has registered.  If the priority given in the RReq-
          PDU is -1, then the registration of highest priority is
          selected for deletion.  Otherwise, only that registration with
          the precise registration is selected.









          M.T. Rose                                             [Page 5]





          draft                        SMUX                February 1990


          4.1.3.  Variables in Requests

          When constructing an SNMP GetRequest-PDU, GetNextRequest-PDU,
          or SetRequest-PDU, for a SMUX peer, the SNMP agent may send
          one, or more than one variable in a single request.  In all
          cases, the SNMP agent should process each variable
          sequentially, and block accordingly when a SMUX peer is
          contacted.


          4.1.4.  Request-ID

          When the SNMP agent constructs an SNMP GetRequest-PDU,
          GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the
          request_id field of the SNMP takes a special meaning.
          Basically, this field should take a different value for each
          SNMP PDU received by the SNMP agent.  As such, if an SNMP
          agent generates multiple PDUs for a SMUX peer, upon receipt of
          a single PDU from the network management station, then the
          request_id field of the PDUs sent to the SMUX peer takes the
          same value (which need bear no relationship to the value of
          the request_id field of the PDU originally received by the
          SNMP agent.)


          4.1.5.  The powerful get-next operator

          Each SMUX peer acts as though it contains the entire MIB when
          processing the power get-next operator.  This means that the
          SNMP agent must check each variable named returned in the SNMP
          GetResponse-PDU generated by a SMUX peer and see if it is in
          the subtree of the managed object corresponding to original
          SNMP GetNextRequest-PDU.  If not, the SNMP agent will apply
          the get-next operator to the next managed object.  This may
          result in contacting a different SMUX peer, depending on the
          registration topology.


          4.2.  Protocol Data Units

          The SMUX protocol data units are defined using Abstract Syntax
          Notation One (ASN.1) [3]:

               SMUX DEFINITIONS ::= BEGIN






          M.T. Rose                                             [Page 6]





          draft                        SMUX                February 1990


               IMPORTS
                       DisplayString, ObjectName
                               FROM RFC1065-SMI

                       PDUs
                               FROM RFC1067-SNMP;


               -- tags for SMUX-specific PDUs are application-wide to
               -- avoid conflict with tags for current (and future)
               -- SNMP-generic PDUs

               SMUX-PDUs ::=
                   CHOICE {
                       open            -- SMUX initiator uses
                           OpenPDU,    -- immediately after TCP open

                       close           -- either uses immediately before TCP close
                           ClosePDU,

                       registerRequest -- SMUX initiator uses
                           RReqPDU,

                       registerResponse -- SNMP agent uses
                           RRspPDU,

                       PDUs            -- note that roles are reversed:
                                       --   SNMP agent does get/get-next/set
                                       --   SMUX initiator does get-response/trap
                   }


               -- open PDU
               -- currently only simple authentication

               OpenPDU ::=
                   CHOICE {
                       simple
                           SimpleOpen
                   }

               SimpleOpen ::=
                   [APPLICATION 0] IMPLICIT
                       SEQUENCE {
                           version     -- of SMUX protocol





          M.T. Rose                                             [Page 7]





          draft                        SMUX                February 1990


                               INTEGER {
                                   version-1(0)
                               },

                           identity    -- of SMUX initiator, authoritative
                               OBJECT IDENTIFIER,

                           description -- of SMUX initiator, implementation-specific
                               DisplayString,

                           password    -- zero length indicates no authentication
                               OCTET STRING
                       }


               -- close PDU

               ClosePDU ::=
                   [APPLICATION 1] IMPLICIT
                       INTEGER {
                           goingDown(0),
                           unsupportedVersion(1),
                           packetFormat(2),
                           protocolError(3),
                           internalError(4),
                           authenticationFailure(5)
                       }


               -- insert PDU

               RReqPDU ::=
                   [APPLICATION 2] IMPLICIT
                       SEQUENCE {
                           subtree
                               ObjectName,

                           priority    -- the lower the better, "-1" means default
                               INTEGER (-1..2147483647),

                           operation
                               INTEGER {
                                   delete(0),
                                   readOnly(1),
                                   readWrite(2)





          M.T. Rose                                             [Page 8]





          draft                        SMUX                February 1990


                               }
                       }

               RRspPDU ::=
                   [APPLICATION 3] IMPLICIT
                       INTEGER {
                           failure(-1)

                           -- on success the non-negative priority is returned
                       }

               END



          4.3.  Mappings on Transport Service

          The SMUX protocol may be mapped onto any CO-mode transport
          service.  At present, only one such mapping is defined.


          4.3.1.  Mapping onto the TCP

          When using the TCP to provide the transport-backing for the
          SMUX protocol, the SNMP agent listens on TCP port 167.

          Each SMUX PDU is serialized using the Basic Encoding Rules [4]
          and sent on the TCP.  As ASN.1 objects are self-delimiting
          when encoding using the BER, no packetization protocol is
          required.




















          M.T. Rose                                             [Page 9]





          draft                        SMUX                February 1990


          5.  MIB for the SMUX

          The MIB objects for the SMUX are implemented by the local SNMP
          agent:

               SMUX-MIB { iso org(3) dod(6) internet(1) private(4) enterprises(1) unix(4)
                               smux(4) }

               DEFINITIONS ::= BEGIN

               IMPORTS
                       unix OBJECT-TYPE
                               FROM RFC1065-SMI;


               -- the SMUX protocol group

               smux    OBJECT IDENTIFIER ::= { unix 4 }

               smuxPeerTable   OBJECT-TYPE
                       SYNTAX  SEQUENCE OF SmuxPeerEntry
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smux 1 }

               smuxPeerEntry   OBJECT-TYPE
                       SYNTAX  SmuxPeerEntry
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxPeerTable 1}

               SmuxPeerEntry ::= SEQUENCE {
                   smuxPindex
                       INTEGER,
                   smuxPidentity
                       OBJECT IDENTIFIER,
                   smuxPdescription
                       DisplayString,
                   smuxPstatus
                       INTEGER
               }

               smuxPindex      OBJECT-TYPE
                       SYNTAX  INTEGER
                       ACCESS  read-write





          M.T. Rose                                            [Page 10]





          draft                        SMUX                February 1990


                       STATUS  mandatory
                       ::= { smuxPeerEntry 1 }

               smuxPidentity   OBJECT-TYPE
                       SYNTAX  OBJECT IDENTIFIER
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxPeerEntry 2 }

               smuxPdescription OBJECT-TYPE
                       SYNTAX  DisplayString
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxPeerEntry 3 }

               smuxPstatus     OBJECT-TYPE
                       SYNTAX  INTEGER { valid(1), invalid(2), connecting(3) }
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxPeerEntry 4 }

               smuxTreeTable   OBJECT-TYPE
                       SYNTAX  SEQUENCE OF SmuxTreeEntry
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smux 2 }

               smuxTreeEntry   OBJECT-TYPE
                       SYNTAX  SmuxTreeEntry
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxTreeTable 1}

               SmuxTreeEntry ::= SEQUENCE {
                   smuxTsubtree
                       ObjectName
                   smuxTpriority
                       INTEGER,
                   smuxTindex
                       INTEGER,
                   smuxTstatus
                       INTEGER
               }

               smuxTsubtree    OBJECT-TYPE





          M.T. Rose                                            [Page 11]





          draft                        SMUX                February 1990


                       SYNTAX  ObjectName
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxTreeEntry 1 }

               smuxTpriority OBJECT-TYPE
                       SYNTAX  INTEGER (0..2147483647)
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxTreeEntry 2 }

               smuxTindex OBJECT-TYPE
                       SYNTAX  INTEGER (0..2147483647)
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxTreeEntry 3 }

               smuxTstatus     OBJECT-TYPE
                       SYNTAX  INTEGER { valid(1), invalid(2) }
                       ACCESS  read-write
                       STATUS  mandatory
                       ::= { smuxTreeEntry 4 }

               END



          5.1.  Identification of OBJECT instances for use with the
          SNMP

          The names for all object types in the MIB are defined
          explicitly either in the Internet-standard MIB or in other
          documents which conform to the naming conventions of the
          SMI[5]. The SMI requires that conformant management protocols
          define mechanisms for identifying individual instances of
          those object types for a particular network element.

          Each instance of any object type defined in the MIB is
          identified in SNMP operations by a unique name called its
          "variable name." In general, the name of an SNMP variable is
          an OBJECT IDENTIFIER of the form x.y, where x is the name of a
          non-aggregate object type defined in the MIB and y is an
          OBJECT IDENTIFIER fragment that, in a way specific to the
          named object type, identifies the desired instance.






          M.T. Rose                                            [Page 12]





          draft                        SMUX                February 1990


          This naming strategy admits the fullest exploitation of the
          semantics of the powerful SNMP get-next operator, because it
          assigns names for related variables so as to be contiguous in
          the lexicographical ordering of all variable names known in
          the MIB.

          The type-specific naming of object instances is defined below
          for a number of classes of object types.  Instances of an
          object type to which none of the following naming conventions
          are applicable are named by OBJECT IDENTIFIERs of the form
          x.0, where x is the name of said object type in the MIB
          definition.

          For example, suppose one wanted to identify an instance of the
          variable sysDescr.  The object class for sysDescr is:

          iso org dod internet mgmt mib system sysDescr
           1   3   6     1      2    1    1       1

          Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which
          is appended an instance sub-identifier of 0.  That is,
          1.3.6.1.2.1.1.1.0 identifies the one and only instance of
          sysDescr.


          5.1.1.  smuxPeerTable Object Type Names

          The name of a SMUX peer relationship, s, is the OBJECT
          IDENTIFIER value of the form i, where i has the value of that
          instance of the smuxPindex object type associated with s.

          For each object type, t, for which the defined name, n, has a
          prefix of smuxPeerEntry, an instance, i, of t is named by an
          OBJECT IDENTIFIER of the form n.s, where s is the name of the
          SMUX peer relationship about which i represents information.

          For example, suppose one wanted to identify the instance of
          the variable smuxPidentity associated with peer relationship
          number 2.  Accordingly, smuxPidentity.2 would identify the
          desired instance.










          M.T. Rose                                            [Page 13]





          draft                        SMUX                February 1990


          5.1.2.  smuxTreeTable Object Type Names

          The name of a SMUX subtree relationship, s, is the OBJECT
          IDENTIFIER value of the form i.j, where i has the value of
          that instance of the smuxTsubtree object type, and j has the
          value of that instance of the smuxTpriority object type,
          associated with s.

          For each object type, t, for which the defined name, n, has a
          prefix of smuxTreeEntry, an instance, i, of t is named by an
          OBJECT IDENTIFIER of the form n.s.t.u, where s is the number
          of sub-identifiers in the corresponding instance of
          smuxTsubtree, t is the value of the instance of smuxTsubtree
          corresponding to this entry, and u is the value of the
          instance of smuxTpriority corresponding to this entry.

          For example, suppose one wanted to identify the instance of
          the variable smuxTindex associated with the subtree 1.3.6.1.5
          for priority 3.  Accordingly, smuxTindex.5.1.3.6.1.5.3 would
          identify the desired instance.






























          M.T. Rose                                            [Page 14]





          draft                        SMUX                February 1990


          6.  References

          [1]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
               Simple Network Management Protocol, Internet Working
               Group Request for Comments 1098.  Network Information
               Center, SRI International, Menlo Park, California,
               (April, 1989).

          [2]  K. McCloghrie and M.T. Rose, Management Information Base
               for Network Management of TCP/IP-based internets,
               Internet Working Group Request for Comments 1066.
               Network Information Center, SRI International, Menlo
               Park, California, (August, 1988).

          [3]  Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).

          [4]  Information processing systems - Open Systems
               Interconnection - Specification of Basic Encoding Rules
               for Abstract Notation One (ASN.1), International
               Organization for Standardization.  International Standard
               8825, (December, 1987).

          [5]  M.T. Rose and K. McCloghrie, Structure and Identification
               of Management Information for TCP/IP-based internets,
               Internet Working Group Request for Comments 1065.
               Network Information Center, SRI International, Menlo
               Park, California, (August, 1988).



















          M.T. Rose                                            [Page 15]





          draft                        SMUX                February 1990


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Introduction ..........................................    2
          3 Architecture ..........................................    3
          4 Protocol ..............................................    4
          4.1 Tricky Things .......................................    4
          4.1.1 Registration ......................................    5
          4.1.2 Removing Registration .............................    5
          4.1.3 Variables in Requests .............................    6
          4.1.4 Request-ID ........................................    6
          4.1.5 The powerful get-next operator ....................    6
          4.2 Protocol Data Units .................................    6
          4.3 Mappings on Transport Service .......................    9
          4.3.1 Mapping onto the TCP ..............................    9
          5 MIB for the SMUX ......................................   10
          5.1 Identification of OBJECT instances  for  use  with
               the SNMP ...........................................   12
          5.1.1 smuxPeerTable Object Type Names ...................   13
          5.1.2 smuxTreeTable Object Type Names ...................   14
          6 References ............................................   15




























          M.T. Rose                                            [Page 16]

