SNMP over IPX
draft-ietf-mpsnmp-overipx-01
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 1420.
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 (Latest revision 1992-08-20) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | thumper.bellcore.com%3A~/pub/snmp-foo/archive | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | RFC 1420 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-mpsnmp-overipx-01
Internet Draft SNMP over IPX August 1992
SNMP over IPX
Tuesday August 11, 1992
Steve Bostock
Novell, Inc.
steveb@novell.com
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 over a Multi-protocol
Internet" working group, it will be submitted to the RFC
editor as a Proposed Standard protocol specification.
If published as an RFC, this document will obsolete RFC 1298.
Bostock Expires February 11, 1993 [Page 1]
Internet Draft SNMP over IPX August 1992
2. Abstract
This document defines a convention for encapsulating Simple
Network Management Protocol (SNMP) [1] packets over the
transport mechanism provided via the Internetwork Packet
Exchange (IPX) protocol [2].
3. Introduction
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
companion standards, which define the Structure of Management
Information (SMI) [3,4], and the Management Information Base
(MIB) [5], the SNMP has received widespread deployment in many
operational networks running the Internet suite of protocols.
The success of SNMP in the TCP/IP environment has led to its
deployment in non TCP/IP-based internets. This specification
describes the mapping of SNMP onto the Internetwork Packet
Exchange (IPX) protocol [2] used in Novell NetWare
environments.
As noted in [6], the preferred mapping for SNMP is onto UDP
[7]. 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.
4. Mapping SNMP onto IPX
Mapping SNMP onto IPX is straight-forward since IPX provides a
datagram service very similar to that provided by IP/UDP.
Although modifications have been made elsewhere in the NetWare
protocol suite, IPX is identical to the Xerox Internet
Datagram Protocol (IDP) [8]. The socket address space
authority is administered by Novell.
SNMP packets will always set the Packet Type field in the IPX
header to 4 (i.e., Packet Exchange Packet).
Bostock Expires February 11, 1993 [Page 2]
Internet Draft SNMP over IPX August 1992
4.1 Socket Assignments
SNMP protocol entities will receive GetRequest-PDU,
GetNextRequest-PDU, and SetRequest-PDU messages on socket
36879 (Destination Socket field set to hexadecimal 900F), and
Trap-PDU messages on socket 36880 (Destination Socket field
set to hexadecimal 9010).
GetResponse-PDU messages will be addressed to the IPX address
and socket from which the corresponding GetRequest-PDU,
GetNextRequest-PDU, or SetRequest-PDU originated.
4.2 Traps
When SNMP traps are sent over IPX, 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
4.3 Maximum Message Size
Although SNMP does not require conformant implementations to
accept messages whose length exceeds 484 bytes, it is
recommended that implementations support a maximum SNMP
message size of 546 bytes (the maximum size allowed under
IPX). Furthermore, this limit is the maximum packet length
guaranteed to traverse IPX routers which do not provide
fragmentation. Implementors may choose to use longer packet
lengths if the maximum is known, which depends on the
intermediate routers and/or intermediate datalink layer
protocols.
4.4 SNMP Party Information
There are occasions when it is necessary to represent a
transport service address in a MIB. For instance, the SNMP
party MIB [9] uses an OBJECT IDENTIFIER to define the
transport domain (IP, IPX, etc.) and an OCTET STRING to
represent an address within that domain. The following
definitions are provided for use in such a scheme.
RFCyyyy-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental
FROM RFC1155-SMI;
Bostock Expires February 11, 1993 [Page 3]
Internet Draft SNMP over IPX August 1992
snmpOverIpx
OBJECT IDENTIFIER ::= { experimental xx }
snmpOverIpxDomain
OBJECT IDENTIFIER ::= { snmpOverIpx 1}
-- For snmpOverIpxDomain, a TAddress is 12 octets long and
-- comprises 3 fields, each in network-byte (high-low) order.
-- The first field is 4 octets long and contains the network
-- number.
-- The next field is 6 octets long and contains the physical
-- address of the node. Since IPX can run over a variety of
-- subnet architectures, the physical node address may not
-- require all 6 octets. As specified in [2], the physical
-- node address will occupy the least significant portion of
-- the field and the most significant octets should be set
-- to zero.
-- The last field is 2 octets long and contains the socket
-- number.
-- 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.
initialIPXPartyId
OBJECT IDENTIFIER ::= { snmpOverIpx 2 }
-- This prefix is used in an analogous fashion as
--
-- initialPartyId
--
-- as defined in [9]. For an SNMP protocol entity residing
-- at IPX transport address 'N', the identities of its six
-- initial parties are formed by appending 12 sub identifiers,
-- one sub-identifier for each octet in the IPX transport
-- address, to
--
Bostock Expires February 11, 1993 [Page 4]
Internet Draft SNMP over IPX August 1992
-- initialIPXPartyId
--
END
5. Document Procurement
This section provides contact points for procurement of
selected documents.
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001
The specification for IDP (part of XNS) may be ordered from:
Xerox System Institute
475 Oakmead Parkway
Sunnyvale, CA 94086
Attn.: Fonda Pallone
(415) 813-7164
6. Acknowledgments
This specification was derived from RFC 1298, based on
discussions in the IETF's "SNMP over a Multiprotocol Internet"
working group.
Bostock Expires February 11, 1993 [Page 5]
Internet Draft SNMP over IPX August 1992
7. References
[1]Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC 1157, May 1990.
[2]Novell, Inc., "NetWare System Technical Interface
Overview", part number 883-000780-001, June 1989.
[3]Rose M.T., McCloghrie K., "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC
1155, May 1991.
[4]Rose M.T., McCloghrie K., "Concise MIB Definitions", RFC
1212, March 1991.
[5]Rose M.T., McCloghrie K., "Management Information Base for
Network Management of TCP/IP-based Internets", RFC 1213,
March 1991.
[6]Kastenholz, F., "SNMP Communications Services", RFC 1270,
October 1991.
[7]Postel J.B., "User Datagram Protocol", RFC 768, August
1980.
[8]Xerox System Integration Standard, "Internet Transport
Protocols", XSIS 028112, Xerox Corporation, December 1981.
[9]McCloghrie, K., Davin, J., and J. Galvin, "Definitions of
Managed Objects for Administration of SNMP Parties", RFC
1353, July 1992
8. Security Considerations
Security issues are not discussed in this memo.
Bostock Expires February 11, 1993 [Page 6]
Internet Draft SNMP over IPX August 1992
9. Author's Address
Steve Bostock
Novell, Inc.
2180 Fortune Drive
San Jose, CA 95131
Phone: 408 473 8203
Fax: 408 435 1706
Email: steveb@novell.com
Bostock Expires February 11, 1993 [Page 7]