Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Obsoleted by:1420 INFORMATIONAL
Network Working Group                                         R. WormleyRequest for Comments: 1298                                    S. Bostock                                                            Novell, Inc.                                                           February 1992SNMP over IPXStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard.  Distribution of this memo is   unlimited.Abstract   This memo 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].Editor's Note   As stated below and in reference [5], it is strongly advised that for   interoperability, SNMP be implemented over UDP/IP and not directly on   media or other protocols (such as IPX).1.  Introduction   The SNMP protocol has been specified as the official network   management protocol of the Internet.  Its widespread acceptance and   implementation by developers, both inside and outside the Internet   community, is fostering synergetic growth to a variety of protocols   and platforms.   This memo addresses the use of SNMP over the IPX protocol, which has   become quite widespread principally due to the popularity of Novell   NetWare.  Roughly equivalent to UDP in function, IPX provides   connectionless, unacknowledged datagram service over a variety of   physical media and protocols.   Although modifications have been made elsewhere in the NetWare   protocol suite, IPX is identical to the Xerox Internet Datagram   Protocol (IDP) [3].  The socket address space authority is   administered by Novell.   The use of SNMP over the UDP transport [4] is today the common mode   of operation in the Internet. This specification may be appropriate   for some environments in which UDP transport services are notWormley & Bostock                                               [Page 1]

RFC 1298                     SNMP over IPX                 February 1992   available.  SNMP implementors should be aware that the choice of   underlying transport may have a significant impact on the   interoperability and ubiquity of the management capability in the   Internet.  Considerations relevant to choosing a transport for use   with SNMP are described in [5].2.  Specification   SNMP packets will always set the Packet Type field in the IPX header   to 4 (i.e., Packet Exchange Packet).2.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.2.2  Maximum Packet Length   Although SNMP does not require conformant implementations to accept   messages whose length exceed 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.2.3  The agent-addr Field for the Trap-PDU   The agent-addr field in a Trap-PDU emitted by an SNMP agent should   contain the IpAddress 0.0.0.0.  An SNMP manager may ascertain the   source of the trap by querying the transport layer.2.4  IPX Transport Address Representation   There are occasions when it is necessary to represent a transport   service address in a MIB.  For instance, the SNMP party MIB [6] 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.Wormley & Bostock                                               [Page 2]

RFC 1298                     SNMP over IPX                 February 1992RFC1298-MIB DEFINITIONS ::= BEGIN    IMPORTS      enterprises         FROMRFC1155-SMI;      novell              OBJECT IDENTIFIER ::= { enterprises 23 }      transportDomains    OBJECT IDENTIFIER ::= { novell 7 }      ipxTransportDomain  OBJECT IDENTIFIER ::= { transportDomains 1 }    -- Authoritatively names the IPX Transport Domain    IpxTransportAddress ::= OCTET STRING (SIZE (12))    -- A textual convention denoting a transport service address in    -- the ipxTransportDomain.  An IpxTransportAddress 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. END3.  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 5463Wormley & Bostock                                               [Page 3]

RFC 1298                     SNMP over IPX                 February 1992       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-71644.  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] Novell, Inc., "NetWare System Technical Interface Overview", June       1989.   [3] Xerox System Integration Standard, "Internet Transport       Protocols", XSIS 028112, Xerox Corporation, December 1981.   [4] Postel, J., "User Datagram Protocol,"RFC 768, USC/Information       Sciences Institute, 28 August 1980.   [5] Kastenholz, F., "SNMP Communications Services,"RFC 1270,       Clearpoint Research Corporation, October 1991.   [6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed       Objects for Administration of SNMP Parties", RFC in preparation.5.  Security Considerations   Security issues are not discussed in this memo.Wormley & Bostock                                               [Page 4]

RFC 1298                     SNMP over IPX                 February 19926.  Authors' Addresses   Raymond Brett Wormley   Novell, Inc.   2180 Fortune Drive   Mail Stop F5-91-2   San Jose, CA 95131   Phone: 408 473 8208   EMail: bwormley@novell.com   Steve Bostock   Novell, Inc.   2180 Fortune Drive   Mail Stop F5-91-2   San Jose, CA 95131   Phone: 408 473 8203   EMail: steveb@novell.comWormley & Bostock                                               [Page 5]

[8]ページ先頭

©2009-2025 Movatter.jp