HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:43:58 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 09 Dec 1992 04:38:00 GMT ETag: "3ddde8-3421-2b257828" Accept-Ranges: bytes Content-Length: 13345 Connection: close Content-Type: text/plain Internet Draft SNMP over OSI July 92 SNMP over OSI Tue Jul 14 19:58:54 1992 Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This draft document is being circulated for comment. If consensus is reached in the IETF's "SNMP in a Multi-Protocol Internet" working group, it will be submitted to the RFC editor as a Proposed Standard protocol specification. Please send comments to the author. If published as an RFC, this document will obsolete RFCs 1161 and 1283. Rose Expires January 14, 1993 [Page 1] Internet Draft SNMP over OSI July 92 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,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]. As such, 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 heterogeneous transport environment, a managed agent should support more than one mapping. Conversely, management stations are strongly encouraged to support mappings of SNMP onto all popular transports. Rose Expires January 14, 1993 [Page 2] Internet Draft SNMP over OSI July 92 3. 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.) 3.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. Rose Expires January 14, 1993 [Page 3] Internet Draft SNMP over OSI July 92 3.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 transport service (i.e., from the T-UNIT-DATA.INDICATION primitive). 3.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.4. Party Information For use with the Party MIB [9], SNMP mapped onto the CLTS (using a CL-mode network service) is referenced as the "rfcXxxxlDomain". Similarly, SNMP mapped onto the CLTS (using a CO-mode network service) is referenced as the "rfcXxxxoDomain". Rose Expires January 14, 1993 [Page 4] Internet Draft SNMP over OSI July 92 RFCxxxx DEFINITIONS ::= BEGIN IMPORTS experimental FROM RFC1155-SMI; -- If this document is issued as an RFC -- -- then these OID assignments will be changed -- snmpOverOSI OBJECT IDENTIFIER ::= { experimental xx } snmpOverOSIdomains OBJECT IDENTIFIER ::= { smpOverOSI 1 } rfcXxxxlDomain OBJECT IDENTIFIER ::= { snmpOverOSIdomains 1 } rfcXxxxoDomain OBJECT IDENTIFIER ::= { snmpOverOSIdomains 2 } -- For either rfcXxxxlDomain or rfcXxxxoDomain, a -- TAddress is `m' octets long. The initial octet -- indicates the length of the NSAP, `n', octets 2 -- through `n+1' contain the NSAP using the concrete -- binary representation, and the remaining octets (if any) -- contain the transport selector. Rose Expires January 14, 1993 [Page 5] Internet Draft SNMP over OSI July 92 -- When devices are installed, they need to be configured -- with an initial set of SNMP parties. The configuration -- of SNMP parties requires (among other things) the -- assignment of several OBJECT IDENTIFIERs. Any local network -- administration can obtain the delegated authority necessary -- to assign its own OBJECT IDENTIFIERs. However, to cater -- for those administrations who have not obtained the necessary -- authority, this document allocates a branch of the naming -- tree for use with the following conventions. initialOSIPartyId OBJECT IDENTIFIER ::= { snmpOverOSI 2 } -- This prefix is used in an analogous fashion as -- -- initialPartyId -- -- as defined in [9]. For an SNMP protocol entity residing at -- NSAP `N' (with length `n'), the identities of its six initial -- parties are formed by appending `n' sub-identifiers, one -- sub-identifier for each octet in the NSAP, to -- -- initialOSIPartyId -- -- NB: 1. If the device being configured has at least one -- IP-address, then the initialPartyId prefix defined in -- the Party MIB should be used instead of the -- initialOSIPartyId prefix. -- -- 2. Use of the initialOSIPartyId prefix is not necessary -- for operation of the SNMP over the CLTS. END Rose Expires January 14, 1993 [Page 6] Internet Draft SNMP over OSI July 92 4. Security Considerations Security issues are not discussed in this memo. 5. Acknowledgements This specification was derived from RFC 1283, based on discussions in the IETF's "SNMP in a Multi-Protocol Internet" working group. Rose Expires January 14, 1993 [Page 1] Internet Draft SNMP over OSI July 92 6. References [1] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol. Request for Comments 1157, (May, 1990). [2] M.T. Rose, K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets. Request for Comments 1155, (May, 1990). [3] M.T. Rose, K. McCloghrie, Concise MIB Definitions. Request for Comments 1212, (March, 1991). [4] K. McCloghrie, M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets. Request for Comments 1213, (March, 1991). [5] F. Kastenholz, SNMP Communication Services. Request for Comments 1270, (October, 1991). [6] J.B. Postel, User Datagram Protocol. Request for Comments 768, (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). [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). [9] K. McCloghrie, J.D. Davin, J.M. Galvin, Definitions of Managed Objects for Administration of SNMP Parties. Request for Comments 1353, (July, 1992). Rose Expires January 14, 1993 [Page 2] Internet Draft SNMP over OSI July 92 Table of Contents 1 Status of this Memo ................................... 1 2 Background ............................................ 2 3 Mapping onto the CLTS ................................. 3 3.1 Well-known Addresses ................................ 3 3.2 Traps ............................................... 4 3.3 Maximum Message Size ................................ 4 3.4 Party Information ................................... 4 4 Security Considerations ............................... 1 5 Acknowledgements ...................................... 1 6 References ............................................ 2 Rose Expires January 14, 1993 [Page 3]