RFC 1161

RFC 1161: SNMP over OSI 💖

Okay bestie, let's get you set up 🎀 This is RFC 1161, "SNMP over OSI," written by M. Rose (editor) at Performance Systems International, Inc., dated June 1990 🦋 It's an experimental memo (see Section 1), not an Internet standard, and the title block doesn't list anything it obsoletes or updates ✨

Here's the table of contents, copied exactly so you can see the whole layout 💅

Table of Contents

   1. Status of this Memo ...................................    1
   2. Background ............................................    1
   2.1 A Digression on User Interfaces ......................    2
   2.1.1 Addressing Conventions for UDP-based service .......    3
   2.2 A Digression of Layering .............................    3
   3. Mapping onto CLTS .....................................    4
   3.1 Addressing Conventions ...............................    4
   3.1.1 Conventions for CLNP-based service .................    4
   4. Mapping onto COTS .....................................    4
   4.1 Addressing Conventions ...............................    5
   4.1.1 Conventions for TP4/CLNP-based service .............    5
   4.1.2 Conventions for TP0/X.25-based service .............    6
   5. Acknowledgements ......................................    6
   6. References ............................................    7
   7. Security Considerations................................    8
   8. Author's Address.......................................    8

---

1. Status of this Memo 🌸

Okay so this memo defines an experimental way to run the Simple Network Management Protocol (SNMP) over OSI transports 🧚

It does not specify a standard for the Internet community 🙈 BUT if enough consensus forms in the Internet community after experimenting, a later revision of this document might become an Internet standard for systems that choose to implement SNMP over OSI transport services ✨

Distribution of this memo is unlimited 🌈

2. Background ⭐

SNMP as defined in [1] is now an integral part of the network management framework for TCP/IP-based internets. Together with its companion standards, which define the Structure of Management Information (SMI) [2] and the Management Information Base (MIB) [3], SNMP has seen widespread deployment in many operational networks running the Internet suite of protocols 💜

It makes total sense that lots of these sites might pick up OSI capabilities and want to keep their SNMP investment and use it to manage those OSI components 🫶 That's what this memo is for: it defines a framework for running SNMP in an environment that supports the OSI transport services 🔥

OSI has two such services. There's a connection-oriented transport service (COTS) as defined in [4], and a connectionless-mode transport service (CLTS) as defined in [5]. The main way SNMP gets deployed today is over the connectionless-mode transport service provided by the Internet suite of protocols (the User Datagram Protocol, or UDP [6]). But one of SNMP's design goals was to be able to use either a CO-mode or a CL-mode transport service, so this memo describes mappings from SNMP onto both the COTS and the CLTS 💖

2.1. A Digression on User Interfaces 🍓

It's likely that user interfaces to SNMP will be built to support multiple transport backings. In that kind of environment, it's often important to keep one consistent addressing scheme for users 💅 Since the mappings in this memo go onto the OSI transport services, use of the textual scheme described in [7] is recommended. That scheme describes a string encoding for OSI presentation addresses ✨ The syntax defined in [7] is equally applicable to transport addresses 🦋

In this context, a string encoding usually looks like this:

[<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>.

This memo is not trying to be an exhaustive guide to string encodings like these 🙈 Readers should consult [7] for the detailed syntax. However, this memo recommends that, as an implementation option, user interfaces to SNMP that support multiple transport backings SHOULD implement this syntax 🎀

2.1.1. Addressing Conventions for UDP-based service 🧚

For a UDP-based transport backing, addresses would be encoded like this:

Internet=<host>+161+2

Which says the transport service is from the Internet suite of protocols, residing at <host>, on port 161, using UDP (2) 🌸 The token <host> can be either a domain name or a dotted-quad. Both of these are valid, e.g.:

Internet=cheetah.nyser.net+161+2

and

Internet=192.52.180.1+161+2

Heads up though: if the domain name "cheetah.nyser.net" maps to multiple IP addresses, that implies multiple transport addresses 👀 How many addresses the application examines (and in what order) is specific to each application 💖

Of course, this memo doesn't require that other interface schemes can't be used 💅 Using a simple hostname is clearly preferable to the string encoding above 🍓 But for the sake of uniformity, it is strongly RECOMMENDED that user interfaces to SNMP that support multiple transport backings adopt the syntax in [7], and that even the mapping for UDP-based transport be valid 👑

2.2. A Digression of Layering 🦋

Other frameworks treat network management as an application, but extensive experience with SNMP suggests otherwise 🙃 Basically, network management is a function unlike any other user of a transport service 🔥 The citation [8] develops this argument in full. Because of that, it's inappropriate to map SNMP onto the OSI application layer. Instead, it's mapped to OSI transport services, so it can build on the proven success of the Internet network management framework 🫶

3. Mapping onto CLTS 💜

Mapping SNMP onto the CLTS is straightforward: the elements of procedure are identical to those used with UDP ✨ The CLTS and the service UDP offers both transmit packets that contain full addressing information, so mapping SNMP onto the CLTS is simple. A "transport address" in the context of [1] is just a transport-selector and a network address 🧚

3.1. Addressing Conventions 🌈

Unlike the Internet suite of protocols, OSI doesn't use well-known ports 😭 Instead, demultiplexing happens on the basis of "selectors." These are opaque strings of octets that only have meaning at the destination. To foster interoperable implementations of SNMP over the CLTS, a selector needs to be defined for this purpose 💅

3.1.1. Conventions for CLNP-based service 🍓

When the CLTS provides the transport backing for SNMP, demultiplexing occurs on the basis of the transport selector. The transport selector used shall be the four ASCII characters snmp 🌸

So using the string encoding from [7], 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, by convention, SNMP traps are sent to a manager listening on the transport selector snmp-trap, which consists of nine ASCII characters 🔔

4. Mapping onto COTS 🔥

Mapping SNMP onto the COTS is trickier, since SNMP doesn't specifically require an existing connection 🙈 So the mapping goes like this: establish a transport connection, send one or more SNMP messages on that connection, then release the transport connection ✨

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

Ideally, the transport connection SHOULD be released by the initiator. Note, though, that the responder may release the connection due to resource limitations 😬 Also, the amount of time a connection stays 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 using a connection. Things like retransmission of SNMP messages always remain with the SNMP application, not with the transport service 💅

4.1. Addressing Conventions 🧚

Same deal as before: OSI doesn't use well-known ports 🦋 Demultiplexing happens on the basis of "selectors," which are opaque strings of octets that only have meaning at the destination. To foster interoperable implementations of SNMP over the COTS, a selector needs to be defined for this purpose 🌸 Since the conventions should line up with the various connectivity-services, different conventions will be used based on the actual underlying service 👑

4.1.1. Conventions for TP4/CLNP-based service 🌈

When a COTS based on TP4/CLNP provides the transport backing for SNMP, demultiplexing occurs on the basis of the transport selector. The transport selector used shall be the four ASCII characters snmp 💜

So using the string encoding from [7], 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, by convention, SNMP traps are sent to a manager listening on the transport selector snmp-trap, which consists of nine ASCII characters 🔔

4.1.2. Conventions for TP0/X.25-based service 🍓

When a COTS based on TP0/X.25 provides the transport backing for SNMP, demultiplexing occurs on the basis of the X.25 protocol-ID. The protocol-ID used shall be the four octets 03018200 🫶

So using the string encoding from [7], 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, by convention, SNMP traps are sent to a manager listening on the protocol-ID 03019000 ✨

5. Acknowledgements ✨

okay so this doc was made by the SNMP Working Group, and the squad list is literally iconic 💅 (all of them 🫶):

      Karl Auerbach, Epilogue Technology
      David Bridgham, Epilogue Technology
      Brian Brown, Synoptics
      John Burress, Wellfleet
      Jeffrey D. Case, University of Tennessee at Knoxville
      James R. Davin, MIT-LCS
      Mark S. Fedor, PSI, Inc.

      Stan Froyd, ACC
      Satish Joshi, Synoptics
      Ken Key, University of Tennessee at Knoxville
      Gary Malkin, FTP Software
      Randy Mayhew, University of Tennessee at Knoxville
      Keith McCloghrie, Hughes LAN Systems
      Marshall T. Rose, PSI, Inc. (chair) 👑
      Greg Satz, cisco
      Martin Lee Schoffstall, PSI, Inc.
      Bob Stewart, Xyplex
      Geoff Thompson, Synoptics
      Bill Versteeg, Network Research Corporation
      Wengyik Yeong, PSI, Inc.

6. References 📚

these are the sources the doc leans on, bestie, so here they are in full 🤓

  [1]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
       Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, and MIT Laboratory for Computer Science, May 1990.

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

  [3]  McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1156, Hughes
       LAN Systems, Performance Systems International, May 1990.

  [4]  Information Processing Systems - Open Systems Interconnection,
       "Transport Service Definition", International Organization for
       Standardization, International Standard 8072, June 1986.

  [5]  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.

  [6]  Postel, J., "User Datagram Protocol", RFC 768, USC/Information
       Sciences Institute, November 1980.

  [7]  Kille, S., "A String Encoding of Presentation Address", Research
       Note RN/89/14, Department of Computer Science, University College
       London, February 1989.

  [8]  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.

7. Security Considerations 🔐

okay the tea is… security issues are not discussed in this memo 🙈 so there's nothing new to spill here, but it's giving "check the other docs before you ship" energy 💀

8. Author's Address 🦋

this is where you can find the author, Marshall T. Rose 💜

   Marshall T. Rose
   PSI, Inc.
   PSI California Office
   P.O. Box 391776
   Mountain View, CA 94039

   Phone: (415) 961-3380

   Email: mrose@PSI.COM

---

and that's a wrap on RFC 1161, periodt ✨🎀💖