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]
