summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1161.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1161.txt')
-rw-r--r--doc/rfc/rfc1161.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1161.txt b/doc/rfc/rfc1161.txt
new file mode 100644
index 0000000..5f957a9
--- /dev/null
+++ b/doc/rfc/rfc1161.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group M. Rose, Editor
+Request for Comments: 1161 Performance Systems International, Inc.
+ June 1990
+
+
+ SNMP over OSI
+
+ 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
+
+ This memo defines an experimental means for running the Simple
+ Network Management Protocol (SNMP) over OSI transports.
+
+ This memo does not specify a standard for the Internet community,
+ However, after experimentation, if sufficient consensus is reached in
+ the Internet community, then a subsequent revision of this document
+ might be made an Internet standard for those systems choosing to
+ implement the SNMP over OSI transport services.
+
+ Distribution of this memo is unlimited.
+
+2. 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], and
+ the Management Information Base (MIB) [3], the SNMP has received
+ widespread deployment in many operational networks running the
+ Internet suite of protocols.
+
+
+
+IETF SNMP Working Group [Page 1]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+ 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 transport services.
+
+ In OSI, there are two such services, a connection-oriented transport
+ services (COTS) as defined in [4], and a connectionless-mode
+ transport service (CLTS) as defined in [5]. Although the primary
+ deployment of the SNMP is over the connectionless-mode transport
+ service provided by the Internet suite of protocols (i.e., the User
+ Datagram Protocol or UDP [6]), a design goal of the SNMP was to be
+ 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 the
+ CLTS.
+
+2.1. A Digression on User Interfaces
+
+ It is likely that user-interfaces to the SNMP will be developed that
+ support multiple transport backings. In an environment such as this,
+ it is often important to maintain a consistent addressing scheme for
+ users. Since the mappings described in this memo are onto the OSI
+ transport services, use of the textual scheme described in [7], which
+ describes a string encoding for OSI presentation addresses, is
+ recommended. The syntax defined in [7] is equally applicable towards
+ transport addresses.
+
+ In this context, a string encoding usually appears as:
+
+ [<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>.
+
+
+
+IETF SNMP Working Group [Page 2]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+ It is not the purpose of this memo to provide an exhaustive
+ description of string encodings such as these. Readers should
+ consult [7] for detailed information on the syntax. However, this
+ memo recommends that, as an implementation option, user-interfaces to
+ the SNMP that support multiple transport backings SHOULD implement
+ this syntax.
+
+2.1.1. Addressing Conventions for UDP-based service
+
+ In the context of a UDP-based transport backing, addresses would be
+ encoded as:
+
+ Internet=<host>+161+2
+
+ which says that the transport service is from the Internet suite of
+ protocols, residing at <host>, on port 161, using the UDP (2). The
+ token <host> may be either a domain name or a dotted-quad, e.g., both
+
+ Internet=cheetah.nyser.net+161+2
+
+ and
+
+ 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 transport
+ addresses. The number of addresses examined by the application (and
+ the order of examination) are specific to each application.
+
+ Of course, this memo does not require that other interface schemes
+ not be used. Clearly, use of a simple hostname is preferable to the
+ string encoding above. However, for the sake of uniformity, for
+ those user-interfaces to the SNMP that support multiple transport
+ backings, it is strongly RECOMMENDED that the syntax in [7] be
+ adopted and even the mapping for UDP-based transport be valid.
+
+2.2. A Digression of Layering
+
+ 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 transport
+ 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 on
+ the proven success of the Internet network management framework.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 3]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+3. Mapping onto CLTS
+
+ Mapping the SNMP onto the CLTS is straight-forward: the elements of
+ procedure are identical to that of using the UDP. In particular,
+ 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.
+
+3.1. Addressing Conventions
+
+ Unlike the Internet suite of protocols, OSI does not use well-known
+ ports. Rather demultiplexing occurs on the basis of "selectors",
+ which are opaque strings of octets, which have meaning only at the
+ destination. In order to foster interoperable implementations of the
+ SNMP over the CLTS, it is necessary define a selector for this
+ purpose.
+
+3.1.1. Conventions for CLNP-based service
+
+ When the CLTS is used to provide the transport backing for the SNMP,
+ demultiplexing will occur on the basis of transport selector. The
+ transport selector used shall be the four ASCII characters
+
+ snmp
+
+ Thus, using the string encoding of [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, SNMP traps are, by convention, sent to a manager listening
+ on the transport selector
+
+ snmp-trap
+
+ which consists of nine ASCII characters.
+
+4. Mapping onto COTS
+
+ Mapping the SNMP onto the COTS is more difficult as the SNMP does not
+ specifically require an existing connection. Thus, the mapping
+
+
+
+IETF SNMP Working Group [Page 4]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+ consists of establishing a transport connection, sending one or more
+ SNMP messages on that connection, and then releasing the transport
+ connection.
+
+ Consistent with the SNMP model, the initiator of a connection should
+ not require that responses to a request be returned on that
+ connection. However, if a responder to a connection sends SNMP
+ messages on a connection, then these MUST be in response to requests
+ received on that connection.
+
+ Ideally, the transport connection SHOULD be released by the
+ initiator, however, note that the responder may release the
+ connection due to resource limitations. Further note, that the
+ amount of time a connection remains 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 the use of a
+ connection. Issues such as retransmission of SNMP messages, etc.,
+ always remain with the SNMP application, not with the transport
+ service.
+
+4.1. Addressing Conventions
+
+ Unlike the Internet suite of protocols, OSI does not use well-known
+ ports. Rather demultiplexing occurs on the basis of "selectors",
+ which are opaque strings of octets, which have meaning only at the
+ destination. In order to foster interoperable implementations of the
+ SNMP over the COTS, it is necessary define a selector for this
+ purpose. However, to be consistent with the various connectivity-
+ services, different conventions, based on the actual underlying
+ service, will be used.
+
+4.1.1. Conventions for TP4/CLNP-based service
+
+ When a COTS based on the TP4/CLNP is used to provide the transport
+ backing for the SNMP, demultiplexing will occur on the basis of
+ transport selector. The transport selector used shall be the four
+ ASCII characters
+
+ snmp
+
+ Thus, using the string encoding of [7], such addresses may be
+ textual, described as:
+
+ "snmp"/NS+<nsap>
+
+
+
+
+IETF SNMP Working Group [Page 5]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+ where:
+
+ (1) <nsap> is a hex string defining the nsap, e.g.,
+
+ "snmp"/NS+4900590800200038bafe00
+
+ Similarly, SNMP traps are, by convention, 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 the TP0/X.25 is used to provide the transport
+ backing for the SNMP, demultiplexing will occur on the basis of X.25
+ protocol-ID. The protocol-ID used shall be the four octets
+
+ 03018200
+
+ Thus, using the string encoding of [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, SNMP traps are, by convention, sent to a manager listening
+ on the protocol-ID
+
+ 03019000
+
+5. Acknowledgements
+
+ This document was produced by the SNMP Working Group:
+
+ 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.
+
+
+
+IETF SNMP Working Group [Page 6]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+ 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
+
+ [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.
+
+
+
+IETF SNMP Working Group [Page 7]
+
+RFC 1161 SNMP over OSI June 1990
+
+
+7. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+8. Author's Address
+
+ Marshall T. Rose
+ PSI, Inc.
+ PSI California Office
+ P.O. Box 391776
+ Mountain View, CA 94039
+
+ Phone: (415) 961-3380
+
+ Email: mrose@PSI.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 8]
+ \ No newline at end of file