As per Relevance of the word transport, we have this rfc below:
Network Working Group M.
Request for Comments: 1283 Dover Beach Consulting, Inc
Obsoletes: RFC 1161 December 1991
SNMP over
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Background ............................................ 1
1.1 A Digression on User Interfaces ...................... 2
1.1.1 Addressing Conventions for UDP-based service ....... 3
1.2 A Digression of Layering ............................. 3
2. Mapping onto CLTS ..................................... 3
2.1 Addressing Conventions ............................... 4
2.1.1 Conventions for CLNP-based service ................. 4
3. Mapping onto COTS ..................................... 4
3.1 Addressing Conventions ............................... 5
3.1.1 Conventions for TP4/CLNP-based service ............. 5
3.1.2 Conventions for TP0/X.25-based service ............. 6
4. Trap PDU .............................................. 6
5. Acknowledgements ...................................... 7
6. References ............................................ 7
7. Security Considerations................................ 8
8. Author's Address....................................... 8
1.
The Simple Network Management Protocol (SNMP) as defined in [1]
now used as an integral part of the network management framework
TCP/IP-based internets. Together, with its companions standards
which define the Structure of Management Information (SMI) [2],
the Management Information Base (MIB) [3], the SNMP has
widespread deployment in many operational networks running
Internet suite of protocols
It should not be surprising that many of these sites might
OSI capabilities and may wish to leverage their investment in
technology towards managing those OSI components. This
addresses these concerns by defining a framework for running the
Rose [Page 1]
RFC 1283 SNMP over OSI December 1991
in an environment which supports the OSI transport services
In OSI, there are two such services, a connection-oriented
services (COTS) as defined in [4], and a connectionless-
transport service (CLTS) as defined in [5]. Although the
deployment of the SNMP is over the connectionless-mode
service provided by the Internet suite of protocols (i.e., the
Datagram Protocol or UDP [6]), a design goal of the SNMP was to
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
CLTS
1.1. A Digression on User
It is likely that user-interfaces to the SNMP will be developed
support multiple transport backings. In an environment such as this
it is often important to maintain a consistent addressing scheme
users. Since the mappings described in this memo are onto the
transport services, use of the textual scheme described in [7],
describes a string encoding for OSI presentation addresses,
recommended. The syntax defined in [7] is equally applicable
transport addresses
In this context, a string encoding usually appears as
[selector>/]provider>[+]
where
(1) selector> is usually either an ASCII string
in double-quotes (e.g., "snmp"), or a hexadecimal
(e.g., '736e6d70'H);
(2) provider> is one of several well-known providers of
connectivity-service, one of: "Internet=" for
transport-service from the Internet suite of protocols
"Int-X25=" for the 1980 CCITT X.25 recommendation,
"NS+" for the OSI network service
(3) is an address in a format specific to
provider>; and
(4) is any additional addressing information in
format specific to the provider>.
It is not the purpose of this memo to provide an
description of string encodings such as these. Readers
consult [7] for detailed information on the syntax. However,
Rose [Page 2]
RFC 1283 SNMP over OSI December 1991
memo recommends that, as an implementation option, user-interfaces
the SNMP that support multiple transport backings SHOULD
this syntax
1.1.1. Addressing Conventions for UDP-based
In the context of a UDP-based transport backing, addresses would
encoded as
Internet=+161+2
which says that the transport service is from the Internet suite
protocols, residing at , on port 161, using the UDP (2).
token may be either a domain name or a dotted-quad, e.g.,
Internet=cheetah.nyser.net+161+2
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
addresses. The number of addresses examined by the application (
the order of examination) are specific to each application
Of course, this memo does not require that other interface
not be used. Clearly, use of a simple hostname is preferable to
string encoding above. However, for the sake of uniformity,
those user-interfaces to the SNMP that support multiple
backings, it is strongly RECOMMENDED that the syntax in [7]
adopted and even the mapping for UDP-based transport be valid
1.2. A Digression of
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
service. The citation [8] 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
the proven success of the Internet network management framework
2. Mapping onto
Mapping the SNMP onto the CLTS is straight-forward. The elements
procedure are identical to that of using the UDP, with one exception
a slightly different Trap PDU is used. Further, note that the
Rose [Page 3]
RFC 1283 SNMP over OSI December 1991
and the service offered by the UDP both transmit packets
information which contain full addressing information. Thus,
the SNMP onto the CLTS, a "transport address" in the context of [1],
is simply a transport-selector and network address
2.1. Addressing
Unlike the Internet suite of protocols, OSI does not use well-
ports. Rather demultiplexing occurs on the basis of "selectors",
which are opaque strings of octets, which have meaning only at
destination. In order to foster interoperable implementations of
SNMP over the CLTS, it is necessary define a selector for
purpose
2.1.1. Conventions for CLNP-based
When the CLTS is used to provide the transport backing for the SNMP
demultiplexing will occur on the basis of transport selector.
transport selector used shall be the four ASCII
Thus, using the string encoding of [7], such addresses may
textual, described as
"snmp"/NS+
where
(1) is a hex string defining the nsap, e.g.,
"snmp"/NS+4900590800200038bafe00
Similarly, SNMP traps are, by convention, sent to a manager
on the transport
snmp-
which consists of nine ASCII characters
3. Mapping onto
Mapping the SNMP onto the COTS is more difficult as the SNMP does
specifically require an existing connection. Thus, the
consists of establishing a transport connection, sending one or
SNMP messages on that connection, and then releasing the
connection. Further, a slightly different Trap PDU is used
Rose [Page 4]
RFC 1283 SNMP over OSI December 1991
Consistent with the SNMP model, the initiator of a connection
not require that responses to a request be returned on
connection. However, if a responder to a connection sends
messages on a connection, then these MUST be in response to
received on that connection
Ideally, the transport connection SHOULD be released by
initiator, however, note that the responder may release
connection due to resource limitations. Further note, that
amount of time a connection remains established is implementation
specific. Implementors should take care to choose an
dynamic algorithm
Also consistent with the SNMP model, the initiator should
associate any reliability characteristics with the use of
connection. Issues such as retransmission of SNMP messages, etc.,
always remain with the SNMP application, not with the
service
3.1. Addressing
Unlike the Internet suite of protocols, OSI does not use well-
ports. Rather demultiplexing occurs on the basis of "selectors",
which are opaque strings of octets, which have meaning only at
destination. In order to foster interoperable implementations of
SNMP over the COTS, it is necessary define a selector for
purpose. However, to be consistent with the various connectivity
services, different conventions, based on the actual
service, will be used
3.1.1. Conventions for TP4/CLNP-based
When a COTS based on the TP4/CLNP is used to provide the
backing for the SNMP, demultiplexing will occur on the basis
transport selector. The transport selector used shall be the
ASCII
Thus, using the string encoding of [7], such addresses may
textual, described as
"snmp"/NS+
where
(1) is a hex string defining the nsap, e.g.,
"snmp"/NS+4900590800200038bafe00
Rose [Page 5]
RFC 1283 SNMP over OSI December 1991
Similarly, SNMP traps are, by convention, sent to a manager
on the transport
snmp-
which consists of nine ASCII characters
3.1.2. Conventions for TP0/X.25-based
When a COTS based on the TP0/X.25 is used to provide the
backing for the SNMP, demultiplexing will occur on the basis of X.25
protocol-ID. The protocol-ID used shall be the four
03018200
This is the X.25 protocol-ID assigned for local management purposes
Thus, using the string encoding of [7], such addresses may be
described as
Int-X25=+PID+03018200
where
(1) is the X.121 DTE, e.g.,
Int-X25=23421920030013+PID+03018200
Similarly, SNMP traps are, by convention, sent to a manager
on the protocol-
03019000
This is an X.25 protocol-ID assigned for local purposes
4. Trap
The Trap-PDU defined in [1] is designed to represent traps
on IP networks. As such, a slightly different PDU must be used
representing traps generated on OSI networks
RFC1283 DEFINTIONS ::=
FROM RFC1155-SMI -- [2] --
FROM RFC1157-SNMP -- [1] --
Rose [Page 6]
RFC 1283 SNMP over OSI December 1991
FROM CLNS-MIB -- [9] --;
Trap-PDU ::=
[4]
IMPLICT SEQUENCE {
enterprise -- type of object
OBJECT IDENTIFIER, -- trap, see
agent-addr -- address of object
ClnpAddress, --
generic-trap -- generic trap
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present
INTEGER, -- if generic-trap is
--
time-stamp -- time elapsed between the
TimeTicks, -- (re)initialization of
-- network entity and
-- generation of the
variable-bindings -- "interesting"
}
5.
The predecessor of this document (RFC 1161) was produced by the
Working Group, and subsequently modified by the editor to
operational experience gained since the original publication
6.
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
Network Management Protocol (SNMP)", RFC 1157, SNMP Research
Performance Systems International, Performance
Rose [Page 7]
RFC 1283 SNMP over OSI December 1991
International, and MIT Laboratory for Computer Science, May 1990.
[2] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[3] McCloghrie K., and M. Rose, Editors, "Management Information
for Network Management of TCP/IP-based internets", RFC 1213,
Hughes LAN Systems, Performance Systems International,
1991.
[4] Information Processing Systems - Open Systems Interconnection
"Transport Service Definition", International Organization
Standardization, International Standard 8072, June 1986.
[5] Information Processing Systems - Open Systems Interconnection
"Transport Service Definition - Addendum 1: Connectionless-
Transmission", International Organization for Standardization
International Standard 8072/AD 1, December 1986.
[6] Postel, J., "User Datagram Protocol", RFC 768, USC/
Sciences Institute, November 1980.
[7] Kille, S., "A String Encoding of Presentation Address", RFC 1278,
Department of Computer Science, University College London
November 1991.
[8] Case, J., Davin, J., Fedor, M., and M. Schoffstall, "
Management and the Design of SNMP", ConneXions (ISSN 0894-5926),
Volume 3, Number 3, March 1989.
[9] Satz, G., "CLNS MIB for use with CLNP and ES-IS", RFC 1238,
Systems, June 1991.
7. Security
Security issues are not discussed in this memo
8. Author's
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2112
Phone: (415) 968-1052
Email: mrose@dbc.mtview.ca.
X.500: mrose, dbc,
Rose [Page 8]
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
