RFC1298 - SNMP over IPX

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group R. Wormley

Request for Comments: 1298 S. Bostock

Novell, Inc.

February 1992

SNMP over IPX

Status 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 not

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.

RFC1298-MIB DEFINITIONS ::= BEGIN

IMPORTS

enterprises FROM RFC1155-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.

END

3. 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

4. References

[1] Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple

Network Management Protocol (SNMP)", RFC1157, 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," RFC768, USC/Information

Sciences Institute, 28 August 1980.

[5] Kastenholz, F., "SNMP Communications Services," RFC1270,

Clearpoint Research Corporation, October 1991.

[6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed

Objects for Administration of SNMP Parties", RFCin preparation.

5. Security Considerations

Security issues are not discussed in this memo.

6. 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.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航