SNMP over OSI (Obsoleted)

Network Working Group                                           M. Rose
Request for Comments: 1283                 Dover Beach Consulting, Inc.
Obsoletes: RFC <a href="./rfc1161">1161</a>                                       December 1991


                             <span class="h1">SNMP over OSI</span>

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please 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 Contents

      <a href="#section-1">1</a>. Background ............................................    <a href="#page-1">1</a>
      <a href="#section-1.1">1.1</a> A Digression on User Interfaces ......................    <a href="#page-2">2</a>
      <a href="#section-1.1.1">1.1.1</a> Addressing Conventions for UDP-based service .......    <a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a> A Digression of Layering .............................    <a href="#page-3">3</a>
      <a href="#section-2">2</a>. Mapping onto CLTS .....................................    <a href="#page-3">3</a>
      <a href="#section-2.1">2.1</a> Addressing Conventions ...............................    <a href="#page-4">4</a>
      <a href="#section-2.1.1">2.1.1</a> Conventions for CLNP-based service .................    <a href="#page-4">4</a>
      <a href="#section-3">3</a>. Mapping onto COTS .....................................    <a href="#page-4">4</a>
      <a href="#section-3.1">3.1</a> Addressing Conventions ...............................    <a href="#page-5">5</a>
      <a href="#section-3.1.1">3.1.1</a> Conventions for TP4/CLNP-based service .............    <a href="#page-5">5</a>
      <a href="#section-3.1.2">3.1.2</a> Conventions for TP0/X.25-based service .............    <a href="#page-6">6</a>
      <a href="#section-4">4</a>. Trap PDU ..............................................    <a href="#page-6">6</a>
      <a href="#section-5">5</a>. Acknowledgements ......................................    <a href="#page-7">7</a>
      <a href="#section-6">6</a>. References ............................................    <a href="#page-7">7</a>
      <a href="#section-7">7</a>. Security Considerations................................    <a href="#page-8">8</a>
      <a href="#section-8">8</a>. Author's Address.......................................    <a href="#page-8">8</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Background</span>

   The Simple Network Management Protocol (SNMP) as defined in [<a href="#ref-1" title=""A Simple Network Management Protocol (SNMP)"">1</a>] is
   now used as an integral part of the network management framework for
   TCP/IP-based internets.  Together, with its companions standards,
   which define the Structure of Management Information (SMI) [<a href="#ref-2" title=""Structure and Identification of Management Information for TCP/IP-based internets"">2</a>], and
   the Management Information Base (MIB) [<a href="#ref-3" title=""Management Information Base for Network Management of TCP/IP-based internets"">3</a>], the SNMP has received
   widespread deployment in many operational networks running the
   Internet suite of protocols.

   It should not be surprising that many of these sites might acquire
   OSI capabilities and may wish to leverage their investment in SNMP
   technology towards managing those OSI components.  This memo
   addresses these concerns by defining a framework for running the SNMP



<span class="grey">Rose                                                            [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


   in an environment which supports the OSI transport services.

   In OSI, there are two such services, a connection-oriented transport
   services (COTS) as defined in [<a href="#ref-4" title=""Transport Service Definition"">4</a>], and a connectionless-mode
   transport service (CLTS) as defined in [<a href="#ref-5" title=""Transport Service Definition - Addendum 1: Connectionless-mode Transmission"">5</a>].  Although the primary
   deployment of the SNMP is over the connectionless-mode transport
   service provided by the Internet suite of protocols (i.e., the User
   Datagram Protocol or UDP [<a href="#ref-6" title=""User Datagram Protocol"">6</a>]), a design goal of the SNMP was to be
   able to use either a CO-mode or CL-mode transport service.  As such,
   this memo describes mappings from the SNMP onto both the COTS and the
   CLTS.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  A Digression on User Interfaces</span>

   It is likely that user-interfaces to the SNMP will be developed that
   support multiple transport backings.  In an environment such as this,
   it is often important to maintain a consistent addressing scheme for
   users.  Since the mappings described in this memo are onto the OSI
   transport services, use of the textual scheme described in [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>], which
   describes a string encoding for OSI presentation addresses, is
   recommended.  The syntax defined in [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>] is equally applicable towards
   transport addresses.

   In this context, a string encoding usually appears as:

      [<t-selector>/]<n-provider><n-address>[+<n-info>]

      where:

      (1)  <t-selector> is usually either an ASCII string enclosed
           in double-quotes (e.g., "snmp"), or a hexadecimal number
           (e.g., '736e6d70'H);

      (2)  <n-provider> is one of several well-known providers of a
           connectivity-service, one of: "Internet=" for a
           transport-service from the Internet suite of protocols,
           "Int-X25=" for the 1980 CCITT X.25 recommendation, or
           "NS+" for the OSI network service;

      (3)  <n-address> is an address in a format specific to the
           <n-provider>; and,

      (4)  <n-info> is any additional addressing information in a
           format specific to the <n-provider>.

   It is not the purpose of this memo to provide an exhaustive
   description of string encodings such as these.  Readers should
   consult [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>] for detailed information on the syntax.  However, this



<span class="grey">Rose                                                            [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


   memo recommends that, as an implementation option, user-interfaces to
   the SNMP that support multiple transport backings SHOULD implement
   this syntax.

<span class="h4"><a class="selflink" id="section-1.1.1" href="#section-1.1.1">1.1.1</a>.  Addressing Conventions for UDP-based service</span>

   In the context of a UDP-based transport backing, addresses would be
   encoded as:

                           Internet=<host>+161+2

   which says that the transport service is from the Internet suite of
   protocols, residing at <host>, on port 161, using the UDP (2).  The
   token <host> may be either a domain name or a dotted-quad, e.g., both

                     Internet=cheetah.nyser.net+161+2

   and

                        Internet=192.52.180.1+161+2

   are both valid.  Note however that if domain name "cheetah.nyser.net"
   maps to multiple IP addresses, then this implies multiple transport
   addresses.  The number of addresses examined by the application (and
   the order of examination) are specific to each application.

   Of course, this memo does not require that other interface schemes
   not be used.  Clearly, use of a simple hostname is preferable to the
   string encoding above.  However, for the sake of uniformity, for
   those user-interfaces to the SNMP that support multiple transport
   backings, it is strongly RECOMMENDED that the syntax in [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>] be
   adopted and even the mapping for UDP-based transport be valid.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  A Digression of Layering</span>

   Although other frameworks view network management as an application,
   extensive experience with the SNMP suggests otherwise.  In essense,
   network management is a function unlike any other user of a transport
   service.  The citation [<a href="#ref-8" title=""Network Management and the Design of SNMP"">8</a>] develops this argument in full.  As such,
   it is inappropriate to map the SNMP onto the OSI application layer.
   Rather, it is mapped to OSI transport services, in order to build on
   the proven success of the Internet network management framework.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Mapping onto CLTS</span>

   Mapping the SNMP onto the CLTS is straight-forward.  The elements of
   procedure are identical to that of using the UDP, with one exception:
   a slightly different Trap PDU is used.  Further, note that the CLTS



<span class="grey">Rose                                                            [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


   and the service offered by the UDP both transmit packets of
   information which contain full addressing information.  Thus, mapping
   the SNMP onto the CLTS, a "transport address" in the context of [<a href="#ref-1" title=""A Simple Network Management Protocol (SNMP)"">1</a>],
   is simply a transport-selector and network address.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Addressing Conventions</span>

   Unlike the Internet suite of protocols, OSI does not use well-known
   ports.  Rather demultiplexing occurs on the basis of "selectors",
   which are opaque strings of octets, which have meaning only at the
   destination.  In order to foster interoperable implementations of the
   SNMP over the CLTS, it is necessary define a selector for this
   purpose.

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  Conventions for CLNP-based service</span>

   When the CLTS is used to provide the transport backing for the SNMP,
   demultiplexing will occur on the basis of transport selector.  The
   transport selector used shall be the four ASCII characters

                                   snmp

   Thus, using the string encoding of [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>], such addresses may be
   textual, described as:

                             "snmp"/NS+<nsap>

   where:

   (1)  <nsap> is a hex string defining the nsap, e.g.,

                     "snmp"/NS+4900590800200038bafe00

   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the transport selector

                                 snmp-trap

   which consists of nine ASCII characters.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Mapping onto COTS</span>

   Mapping the SNMP onto the COTS is more difficult as the SNMP does not
   specifically require an existing connection.  Thus, the mapping
   consists of establishing a transport connection, sending one or more
   SNMP messages on that connection, and then releasing the transport
   connection.  Further, a slightly different Trap PDU is used.




<span class="grey">Rose                                                            [Page 4]</span>

<span id="page-5" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


   Consistent with the SNMP model, the initiator of a connection should
   not require that responses to a request be returned on that
   connection.  However, if a responder to a connection sends SNMP
   messages on a connection, then these MUST be in response to requests
   received on that connection.

   Ideally, the transport connection SHOULD be released by the
   initiator, however, note that the responder may release the
   connection due to resource limitations.  Further note, that the
   amount of time a connection remains established is implementation-
   specific.  Implementors should take care to choose an appropriate
   dynamic algorithm.

   Also consistent with the SNMP model, the initiator should not
   associate any reliability characteristics with the use of a
   connection.  Issues such as retransmission of SNMP messages, etc.,
   always remain with the SNMP application, not with the transport
   service.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Addressing Conventions</span>

   Unlike the Internet suite of protocols, OSI does not use well-known
   ports.  Rather demultiplexing occurs on the basis of "selectors",
   which are opaque strings of octets, which have meaning only at the
   destination.  In order to foster interoperable implementations of the
   SNMP over the COTS, it is necessary define a selector for this
   purpose.  However, to be consistent with the various connectivity-
   services, different conventions, based on the actual underlying
   service, will be used.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Conventions for TP4/CLNP-based service</span>

   When a COTS based on the TP4/CLNP is used to provide the transport
   backing for the SNMP, demultiplexing will occur on the basis of
   transport selector.  The transport selector used shall be the four
   ASCII characters

                                   snmp

   Thus, using the string encoding of [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>], such addresses may be
   textual, described as:

                             "snmp"/NS+<nsap>
   where:

   (1)  <nsap> is a hex string defining the nsap, e.g.,

                     "snmp"/NS+4900590800200038bafe00



<span class="grey">Rose                                                            [Page 5]</span>

<span id="page-6" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the transport selector

                                 snmp-trap

   which consists of nine ASCII characters.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Conventions for TP0/X.25-based service</span>

   When a COTS based on the TP0/X.25 is used to provide the transport
   backing for the SNMP, demultiplexing will occur on the basis of X.25
   protocol-ID.  The protocol-ID used shall be the four octets

                                 03018200

   This is the X.25 protocol-ID assigned for local management purposes.
   Thus, using the string encoding of [<a href="#ref-7" title=""A String Encoding of Presentation Address"">7</a>], such addresses may be textual
   described as:

                        Int-X25=<dte>+PID+03018200

   where:

   (1)  <dte> is the X.121 DTE, e.g.,

                    Int-X25=23421920030013+PID+03018200

   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the protocol-ID

                                 03019000

   This is an X.25 protocol-ID assigned for local purposes.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Trap PDU</span>

   The Trap-PDU defined in [<a href="#ref-1" title=""A Simple Network Management Protocol (SNMP)"">1</a>] is designed to represent traps generated
   on IP networks.  As such, a slightly different PDU must be used when
   representing traps generated on OSI networks.

   <a href="./rfc1283">RFC1283</a> DEFINTIONS ::= BEGIN

   IMPORTS
        TimeTicks
            FROM <a href="./rfc1155">RFC1155</a>-SMI  -- [<a href="#ref-2" title=""Structure and Identification of Management Information for TCP/IP-based internets"">2</a>] --
        VarBindList
            FROM <a href="./rfc1157">RFC1157</a>-SNMP -- [<a href="#ref-1" title=""A Simple Network Management Protocol (SNMP)"">1</a>] --
        ClnpAddress



<span class="grey">Rose                                                            [Page 6]</span>

<span id="page-7" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


            FROM CLNS-MIB     -- [<a href="#ref-9" title=""CLNS MIB for use with CLNP and ES-IS"">9</a>] --;

   Trap-PDU ::=
        [<a href="#ref-4" title=""Transport Service Definition"">4</a>]
            IMPLICT SEQUENCE {
                enterprise              -- type of object generating
                    OBJECT IDENTIFIER,  -- trap, see sysObjectID

                agent-addr              -- address of object generating
                    ClnpAddress,        -- trap

                generic-trap            -- generic trap type
                    INTEGER {
                        coldStart(0),
                        warmStart(1),
                        linkDown(2),
                        linkUp(3),
                        authenticationFailure(4),
                        egpNeighborLoss(5),
                        enterpriseSpecific(6)
                    },

                specific-trap           -- specific code, present even
                    INTEGER,            -- if generic-trap is not
                                        -- enterpriseSpecific

                time-stamp              -- time elapsed between the last
                    TimeTicks,          -- (re)initialization of the
                                        -- network entity and the
                                        -- generation of the trap

                variable-bindings       -- "interesting" information
                    VarBindList
        }

   END

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Acknowledgements</span>

   The predecessor of this document (<a href="./rfc1161">RFC 1161</a>) was produced by the SNMP
   Working Group, and subsequently modified by the editor to reflect
   operational experience gained since the original publication.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  References</span>

   [<a id="ref-1">1</a>] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
       Network Management Protocol (SNMP)", <a href="./rfc1157">RFC 1157</a>, SNMP Research,
       Performance Systems International, Performance Systems



<span class="grey">Rose                                                            [Page 7]</span>

<span id="page-8" ></span>
<span class="grey"><a href="./rfc1283">RFC 1283</a>                     SNMP over OSI                 December 1991</span>


       International, and MIT Laboratory for Computer Science, May 1990.

   [<a id="ref-2">2</a>] Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", <a href="./rfc1155">RFC 1155</a>,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [<a id="ref-3">3</a>] McCloghrie K., and M. Rose, Editors, "Management Information Base
       for Network Management of TCP/IP-based internets", <a href="./rfc1213">RFC 1213</a>,
       Hughes LAN Systems, Performance Systems International, March
       1991.

   [<a id="ref-4">4</a>] Information Processing Systems - Open Systems Interconnection,
       "Transport Service Definition", International Organization for
       Standardization, International Standard 8072, June 1986.

   [<a id="ref-5">5</a>] Information Processing Systems - Open Systems Interconnection,
       "Transport Service Definition - Addendum 1: Connectionless-mode
       Transmission", International Organization for Standardization,
       International Standard 8072/AD 1, December 1986.

   [<a id="ref-6">6</a>] Postel, J., "User Datagram Protocol", <a href="./rfc768">RFC 768</a>, USC/Information
       Sciences Institute, November 1980.

   [<a id="ref-7">7</a>] Kille, S., "A String Encoding of Presentation Address", <a href="./rfc1278">RFC 1278</a>,
       Department of Computer Science, University College London,
       November 1991.

   [<a id="ref-8">8</a>] Case, J., Davin, J., Fedor, M., and M. Schoffstall, "Network
       Management and the Design of SNMP", ConneXions (ISSN 0894-5926),
       Volume 3, Number 3, March 1989.

   [<a id="ref-9">9</a>] Satz, G., "CLNS MIB for use with CLNP and ES-IS", <a href="./rfc1238">RFC 1238</a>, cisco
       Systems, June 1991.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   Security issues are not discussed in this memo.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Author's Address</span>

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA 94043-2112

   Phone: (415) 968-1052
   Email: [email protected]
   X.500: mrose, dbc, us



Rose                                                            [Page 8]