doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc1418.txt b/doc/rfc/rfc1418.txt
new file mode 100644
index 0000000..bcdf90c
--- /dev/null
+++ b/doc/rfc/rfc1418.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                           M. Rose
+Request for Comments: 1418                 Dover Beach Consulting, Inc.
+Obsoletes: 1161, 1283                                        March 1993
+
+
+                             SNMP over OSI
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   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
+
+   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.  Background
+
+   The Simple Network Management Protocol (SNMP) as defined in [1] 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) [2,3], and
+   the Management Information Base (MIB) [4], 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
+   in an environment which supports the OSI connectionless-mode
+   transport service.
+
+   However, as noted in [5], the preferred mapping for SNMP is onto the
+   UDP [6].  This specification is intended for use in environments
+   where UDP transport is not available.  No aspect of this
+   specification should be construed as a suggestion that, in a
+
+
+
+Rose                                                            [Page 1]
+
+RFC 1418                     SNMP over OSI                    March 1993
+
+
+   heterogeneous transport environment, a managed agent should support
+   more than one mapping.
+
+2.  Mapping onto the CLTS
+
+   Mapping the SNMP onto the CLTS [7,8] is straight-forward.  The
+   elements of procedure are identical to that of using the UDP.  Note
+   that the CLTS 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 [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 architectural
+   principles, as described in [1,5].  However, the CLTS itself can be
+   realized using either a connectionless-mode or a connection-oriented
+   network service.  The mapping described in this mapping allows for
+   either realization.  (When both network services are available, the
+   CLNS should be used as the basis of realization.)
+
+2.1.  Well-known Addresses
+
+   Unlike the Internet suite of protocols, OSI does not use well-known
+   ports.  Rather,
+    demultiplexing occurs on the basis of "selectors", opaque strings of
+   octets which have local significance.  In order to foster
+   interoperable implementations of the SNMP over the CLTS, it is
+   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, then
+   transport selector used shall be "snmp-l" which consists of six ASCII
+   characters; and, SNMP traps are, by convention, sent to an SNMP
+   manager listening on the transport selector "snmpt-l" which consists
+   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, then
+   transport selector used shall be "snmp-o" which consists of six ASCII
+   characters; and, SNMP traps are, by convention, sent to an SNMP
+   manager listening on the transport selector "snmpt-o" which consists
+   of seven ASCII characters.
+
+2.2.  Traps
+
+   When SNMP traps are sent over the CLTS, the agent-addr field in the
+   Trap-PDU contains the IP-address "0.0.0.0" An SNMP manager may
+   ascertain the source of the trap based on information provided by the
+
+
+
+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 Size
+
+   An entity implementing SNMP over OSI must be prepared to accept
+   messages whose size is at least 484 octets.  Implementation of larger
+   values is encouraged whenever possible.
+
+3.  Acknowledgements
+
+   This specification was derived from RFC 1283, based on discussions in
+   the IETF's "SNMP in a Multi-Protocol Internet" working group.
+
+4.  References
+
+   [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [2] Rose M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [3] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+   [4] Rose M., and K. McCloghrie, Editors, "Management Information Base
+       for Network Management of TCP/IP-based Internets", STD 17, RFC
+       1213, Hughes LAN Systems, Inc., Performance Systems
+       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-mode
+       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-mode
+       Transport Service, International Organization for
+       Standardization.  International Standard 8602, December 1987.
+
+5.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Author's Address
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   420 Whisman Court
+   Mountain View, CA 94043-2112
+
+   Phone: (415) 968-1052
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                            [Page 4]
+
\ No newline at end of file