Summary

  • RFC 1283 experimentally mapped SNMP onto both connectionless and connection-oriented OSI transport services. A COTS exchange established a connection, sent one or more messages and released it.
  • The initiator was not entitled to expect the response on that same connection or to assign reliability to the connection. SNMP timeout and retransmission remained application responsibilities.
  • RFC 1418 later removed the COTS mapping and retained a connectionless OSI form for environments without UDP. That changed the specification; it did not prove that every implementation or deployment changed with it.

An experimental revision carried operational memory

RFC 1161 had proposed an experimental way to run SNMP over OSI transports in June 1990. It described both a connectionless-mode transport service, CLTS, and a connection-oriented service, COTS. It was explicit about its status: this was not an Internet standard, although experimentation and sufficient consensus might eventually support a later standard.

Eighteen months later, RFC 1283 obsoleted that first document. It remained Experimental. The editor said the revision reflected operational experience gained since the original publication. That sentence is modest but important. It records a learning process, not a verdict that a particular network had succeeded or failed.

The historical problem was practical. SNMP already had substantial use in TCP/IP networks. Sites acquiring OSI capabilities wanted to reuse that management investment. RFC 1283 therefore mapped SNMP directly to OSI transport services, rather than rebuilding it as an OSI application-layer protocol.

Connectionless transport preserved a familiar message model

The CLTS mapping looked like SNMP over UDP. Both services delivered packets containing full addressing information. In this setting, a transport address was a network address joined to a transport selector.

OSI did not use Internet well-known ports for this job. Demultiplexing used opaque selector octets whose meaning was local to the destination. RFC 1283 coordinated the four ASCII characters snmp for ordinary SNMP traffic and snmp-trap for traps on the CLNP-based service.

Those selectors created interoperability at one narrow boundary. A receiver could know which local service should be offered the transport unit. The selector did not identify a durable device, authenticate a manager, authorize a Set request or prove the variable bindings true. It was a delivery label, not a management mandate.

COTS added a connection without changing the application question

The COTS mapping was harder because SNMP did not naturally require a standing connection. RFC 1283 supplied a sequence: establish a transport connection, send one or more SNMP messages, then release the connection.

That sequence creates three observable states. A connection can fail before it opens. It can open while carrying no complete SNMP request. It can carry bytes and close before the intended application produces a response. Calling all three “the SNMP request failed” discards the location of the failure.

The reverse mistake is more dangerous. A successful connection proves only that the transport association reached its own established state. It does not prove that the addressed process decoded the message, applied its community or access rules, read the named object, committed a Set operation or produced an application result.

The answer did not have to return through the same opening

RFC 1283 preserved an unusual asymmetry. The connection initiator should not require a response to come back on the connection that carried the request. If the responder did send SNMP messages on that connection, however, those messages had to be responses to requests received there.

The open association therefore supplied a conditional correlation rule, not a universal reply path. A response observed on the connection could be joined to work received there. Silence on the connection did not prove that no response existed elsewhere, and the association itself did not provide a durable operation identifier.

The owner of connection lifetime was divided too. Ideally the initiator released it. The responder could close it because of resource limitations. How long it remained open was implementation-specific and required a suitable dynamic algorithm. Closure could consequently describe policy, pressure, idleness or failure. It was not a self-explanatory SNMP outcome.

Transport reliability stopped before SNMP completion

The sharpest sentence in RFC 1283 told the initiator not to associate reliability characteristics with use of a connection. Retransmission of SNMP messages remained with the SNMP application, not the transport service.

RFC 1270, published two months earlier, explained the distinction. A transport acknowledgement did not necessarily mean that data had reached the destination application process. SNMP still needed a timeout and retry procedure to determine whether its own software had received the packet.

This was not a denial that transport reliability mattered. A checksum, ordering and retransmission below the application could improve delivery of bytes. But “these bytes crossed the transport contract” and “the intended management operation completed” were different claims. The latter needed an application response and a correlation rule. Even then, the returned value was evidence reported by an agent, not automatic proof about the physical network.

Connection management imposed its own ledger

RFC 1270 described three ways to manage connection-oriented SNMP: keep one connection open to every managed object; open and close one per operation; or keep a limited pool and replace connections by an algorithm such as least-recently-used. It found serious costs in all three.

Permanent connections consumed records across hundreds or thousands of agents and risked useless keepalive traffic. Per-operation connections repeatedly paid establishment, closure and TIME-WAIT costs. A limited pool required usage state and replacement logic, then tended toward per-operation churn when polling more agents than the pool could hold.

These were not merely performance details. They created ownership questions. Which component decided that an idle connection no longer deserved resources? Which observation justified replacement? Could closing an association erase the only convenient context for correlating a late response? The transport surface solved one problem and created a new state table that had to remain auditable.

The later specification kept the connectionless path

In March 1993, RFC 1418 obsoleted both RFC 1161 and RFC 1283. It retained an OSI connectionless mapping and dropped the COTS section. UDP remained the preferred SNMP transport; the OSI mapping was intended for environments where UDP was unavailable, and an agent was not thereby expected to support several mappings in a heterogeneous network.

The revision also made a subtle layering point visible. CLTS could be realized over either a connectionless or connection-oriented network service, with different selectors for the two cases. The application-facing transport contract remained connectionless even when a lower network service had a connection-oriented form. Architecture could not be inferred from one word applied at the wrong layer.

Obsoletion is evidence about documents. It says which specification replaced another. It does not demonstrate when products removed COTS support, whether a named operator used it, or which transport produced a better result in a real incident.

Sources and limits

This account uses the official texts of RFC 1161, RFC 1270, RFC 1283 and RFC 1418. They establish document status, mapping rules, stated design arguments and revision history. All four say that security issues are not discussed. They do not establish a current implementation, authenticated party, authorized operation, observed request, response, retry, outage or management outcome.