As per Relevance of the word transport, we have this rfc below:
Network Working Group M.
Request for Comments: 1418 Dover Beach Consulting, Inc
Obsoletes: 1161, 1283 March 1993
SNMP over
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
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
2. Mapping onto the CLTS ...................................... 2
2.1 Well-known Addresses ...................................... 2
2.2 Traps ..................................................... 2
2.3 Maximum Message Size ...................................... 3
3. Acknowledgements ........................................... 3
4. References ................................................. 3
5. Security Considerations .................................... 4
6. Author's Address ........................................... 4
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,3],
the Management Information Base (MIB) [4], 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
in an environment which supports the OSI connectionless-
transport service
However, as noted in [5], the preferred mapping for SNMP is onto
UDP [6]. This specification is intended for use in
where UDP transport is not available. No aspect of
specification should be construed as a suggestion that, in
Rose [Page 1]
RFC 1418 SNMP over OSI March 1993
heterogeneous transport environment, a managed agent should
more than one mapping
2. Mapping onto the
Mapping the SNMP onto the CLTS [7,8] is straight-forward.
elements of procedure are identical to that of using the UDP.
that the CLTS and the service offered by the UDP both
packets of information which contain full addressing information
Thus, mapping the SNMP onto the CLTS, a "transport address" in
context of [1], is simply a transport-selector and network address
It should be noted that the mapping of SNMP onto a connectionless
mode transport service is wholly consistent with SNMP's
principles, as described in [1,5]. However, the CLTS itself can
realized using either a connectionless-mode or a connection-
network service. The mapping described in this mapping allows
either realization. (When both network services are available,
CLNS should be used as the basis of realization.)
2.1. Well-known
Unlike the Internet suite of protocols, OSI does not use well-
ports. Rather
demultiplexing occurs on the basis of "selectors", opaque strings
octets which have local significance. In order to
interoperable implementations of the SNMP over the CLTS, it
necessary define four selectors for this purpose
When the CLTS is used to provide the transport backing for the SNMP
and the CLTS uses a connectionless-mode network service,
transport selector used shall be "snmp-l" which consists of six
characters; and, SNMP traps are, by convention, sent to an
manager listening on the transport selector "snmpt-l" which
of seven ASCII characters
When the CLTS is used to provide the transport backing for the SNMP
and the CLTS uses a connection-oriented network service,
transport selector used shall be "snmp-o" which consists of six
characters; and, SNMP traps are, by convention, sent to an
manager listening on the transport selector "snmpt-o" which
of seven ASCII characters
2.2.
When SNMP traps are sent over the CLTS, the agent-addr field in
Trap-PDU contains the IP-address "0.0.0.0" An SNMP manager
ascertain the source of the trap based on information provided by
Rose [Page 2]
RFC 1418 SNMP over OSI March 1993
transport service (i.e., from the T-UNIT-DATA.INDICATION primitive).
2.3. Maximum Message
An entity implementing SNMP over OSI must be prepared to
messages whose size is at least 484 octets. Implementation of
values is encouraged whenever possible
3.
This specification was derived from RFC 1283, based on discussions
the IETF's "SNMP in a Multi-Protocol Internet" working group
4.
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[2] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.
[3] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes
Systems, March 1991.
[4] Rose M., and K. McCloghrie, Editors, "Management Information
for Network Management of TCP/IP-based Internets", STD 17,
1213, Hughes LAN Systems, Inc., Performance
International, March 1991.
[5] Kastenholz, F., "SNMP Communications Services", RFC 1270,
Clearpoint Research Corporation, October 1991.
[6] Postel J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[7] Information processing systems - Open Systems Interconnection -
Transport Service Definition - Addendum 1: Connectionless-
Transmission, International Organization for Standardization
International Standard 8072/AD 1, June 1986.
Rose [Page 3]
RFC 1418 SNMP over OSI March 1993
[8] Information processing systems - Open Systems Interconnection -
Protocol Specification for Providing the Connectionless-
Transport Service, International Organization
Standardization. International Standard 8602, December 1987.
5. Security
Security issues are not discussed in this memo
6. Author's
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2112
Phone: (415) 968-1052
EMail: mrose@dbc.mtview.ca.
Rose [Page 4]
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
