RFC1298 日本語訳

Network Working Group                                         R. Wormley
Request for Comments: 1298                                    S. Bostock
                                                            Novell, Inc.
                                                           February 1992

コメントを求めるワーキンググループR.ワァムリーの要求をネットワークでつないでください: 1298秒間BostockノベルInc.1992年2月

                             SNMP over IPX

IPXの上のSNMP

Status of this Memo

この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].

このメモは、Internetwork Packet Exchange(IPX)プロトコル[2]で提供された移送機構の上でSimple Network Managementプロトコル(SNMP)が[1]パケットであるとカプセル化するためにコンベンションを定義します。

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

それが参照の下と、そして、参照[5]に述べられているように強くアドバイスされる、相互運用性、SNMPのためのそれ、直接メディアか他のプロトコル(IPXなどの)で実装されるのではなく、UDP/IPの上で実装されてください。

1.  Introduction

1. 序論

   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.

SNMPプロトコルはインターネットの公式のネットワーク管理プロトコルとして指定されました。 その広範囲の承認とインターネットコミュニティとインターネットコミュニティの開発者の近くと外の実装はさまざまなプロトコルとプラットホームへの相乗の成長を促進しています。

   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.

このメモはIPXプロトコルの上でSNMPの使用を扱います。プロトコルは主にノベルNetWareの人気のためにかなり広範囲になりました。 およそ機能におけるUDPに同等であることで、IPXはさまざまな物理的なメディアとプロトコルの上にコネクションレスで、不承認のデータグラムサービスを提供します。

   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.

NetWareプロトコル群のほかの場所で変更をしましたが、IPXはゼロックスインターネットデータグラムプロトコル(IDP)[3]と同じです。 ソケットアドレス空間権威はノベルによって管理されます。

   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

今日、UDP輸送[4]の上のSNMPの使用はインターネットの一般的な運転モードです。 いくつかの環境に、この仕様は輸送サービスがどのUDPでないかで適切であるかもしれません。

Wormley & Bostock                                               [Page 1]

RFC 1298                     SNMP over IPX                 February 1992

IPX1992年2月の間のワァムリーとBostock[1ページ]RFC1298SNMP

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

利用可能。 SNMP作成者は輸送の基礎となることの選択がインターネットでの管理能力の相互運用性と偏在に重要な影響を与えるかもしれないのを意識しているべきです。 SNMPとの使用のための輸送を選ぶと関連している問題は[5]で説明されます。

2.  Specification

2. 仕様

   SNMP packets will always set the Packet Type field in the IPX header
   to 4 (i.e., Packet Exchange Packet).

SNMPパケットはいつも4(すなわち、Packet Exchange Packet)へのIPXヘッダーにPacket Type分野をはめ込むでしょう。

2.1  Socket Assignments

2.1 ソケット課題

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

SNMPプロトコル実体はソケット36880に関するGetRequest-PDU、GetNextRequest- PDU、ソケット36879(目的地Socket分野は16進に900Fセットしました)に関するSetRequest-PDUメッセージ、およびTrap-PDUメッセージを受け取るでしょう(目的地Socket分野は16進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.

GetResponse-PDUメッセージは対応するGetRequest-PDU、GetNextRequest- PDU、またはSetRequest-PDUが起因したIPXアドレスとソケットに扱われるでしょう。

2.2  Maximum Packet Length

2.2 最大のパケット長

   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.

SNMPは長さが484バイトを超えているメッセージを受け入れるためにconformant実装を必要としませんが、実装が、最大のSNMPが546バイト(IPXの下に許容された最大サイズ)のメッセージサイズであるとサポートするのは、お勧めです。 その上、この限界は断片化を提供しない横断IPXルータに保証された最大のパケット長です。 最大(中間的ルータ、そして/または、中間的データリンク層のプロトコルによる)が知られているなら、作成者は、より長いパケット長を使用するのを選ぶかもしれません。

2.3  The agent-addr Field for the Trap-PDU

2.3 Trap-PDUのためのエージェント-addr Field

   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.

SNMPエージェントによって放たれたTrap-PDUのエージェント-addr分野がIpAddressを含むべきである、0.0、.0、.0 SNMPマネージャは、トランスポート層について質問することによって、罠の源を確かめるかもしれません。

2.4  IPX Transport Address Representation

2.4 IPX輸送アドレス表現

   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.

輸送サービスアドレスを表すのが必要である時がMIBにあります。 例えば、SNMPパーティーMIB[6]は、そのドメインの中にアドレスを表すために輸送ドメイン(IP、IPXなど)とOCTET STRINGを定義するのにOBJECT IDENTIFIERを使用します。 そのような体系における使用に以下の定義を提供します。

Wormley & Bostock                                               [Page 2]

RFC 1298                     SNMP over IPX                 February 1992

IPX1992年2月の間のワァムリーとBostock[2ページ]RFC1298SNMP

 RFC1298-MIB DEFINITIONS ::= BEGIN

RFC1298-MIB定義:、:= 始まってください。

    IMPORTS
      enterprises         FROM RFC1155-SMI;

IMPORTS企業FROM RFC1155-SMI。

      novell              OBJECT IDENTIFIER ::= { enterprises 23 }
      transportDomains    OBJECT IDENTIFIER ::= { novell 7 }

novell OBJECT IDENTIFIER:、:= 企業23transportDomains OBJECT IDENTIFIER:、:= novell7

      ipxTransportDomain  OBJECT IDENTIFIER ::= { transportDomains 1 }

ipxTransportDomainオブジェクト識別子:、:= transportDomains1

    -- Authoritatively names the IPX Transport Domain

-- 厳然と、IPX Transport Domainを命名します。

    IpxTransportAddress ::= OCTET STRING (SIZE (12))

IpxTransportAddress:、:= 八重奏ストリング(サイズ(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.

-- 輸送を指示するとアドレスが修理される原文のコンベンション--ipxTransportDomain。 IpxTransportAddressはそれぞれネットワークバイト(高い低い)で12八重奏--長さであり、3つの分野を包括します--オーダー。

    -- The first field is 4 octets long and contains the network
    -- number.

-- 最初の分野は、長い間の4つの八重奏であり、ネットワークを含んでいます--数。

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

-- 次の分野は、長い間の6つの八重奏であり、物理的を含んでいます--ノードのアドレス。 以来にIPXがあふれることができる、様々である、--サブネットアーキテクチャ、物理的なノードアドレスはそうしないかもしれません--すべての6つの八重奏を必要としてください。 [2]で指定されるように、物理的--アドレスが占領する中で部分最も重要でないノード--分野と最も重要な八重奏は設定されるべきです--ゼロに合わせるために。

    -- The last field is 2 octets long and contains the socket
    -- number.

-- 最後の分野は、長い間の2つの八重奏であり、ソケットを含んでいます--数。

 END

終わり

3.  Document Procurement

3. ドキュメント調達

   This section provides contact points for procurement of selected
   documents.

このセクションは選択されたドキュメントの調達のための接点を提供します。

   A complete description of IPX may be secured at the following
   address:

以下のアドレスでIPXの完全な記述を保証するかもしれません:

       Novell, Inc.
       122 East 1700 South
       P. O. Box 5900
       Provo, Utah 84601 USA
       800 526 5463

1700年の東南P. O. Box5900プロボ、ノベルInc.122ユタ84601米国800 526 5463

Wormley & Bostock                                               [Page 3]

RFC 1298                     SNMP over IPX                 February 1992

IPX1992年2月の間のワァムリーとBostock[3ページ]RFC1298SNMP

       Novell Part # 883-000780-001

ノベル部分#883-000780-001

   The specification for IDP (part of XNS) may be ordered from:

IDP(XNSの一部)のための仕様は以下に注文されるかもしれません。

       Xerox System Institute
       475 Oakmead Parkway
       Sunnyvale, CA 94086
       Attn: Fonda Pallone
       (415) 813-7164

ゼロックスシステム研究所475Oakmead Parkwayサニーベル(カリフォルニア)94086Attn: フォンダパローネ(415)813-7164

4.  References

4. 参照

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

[1] J.、ヒョードルM.、Schoffstall M.、J.デーヴィン、「簡単なネットワーク管理プロトコル(SNMP)」、RFC1157、SNMP研究、国際言語運用機構、国際言語運用機構、およびMITコンピュータサイエンス研究所(1990年5月)をケースに入れてください。

   [2] Novell, Inc., "NetWare System Technical Interface Overview", June
       1989.

[2]ノベルInc.、「NetWareシステム技術的インタフェース概要」、1989年6月。

   [3] Xerox System Integration Standard, "Internet Transport
       Protocols", XSIS 028112, Xerox Corporation, December 1981.

[3] 標準のゼロックスシステムインテグレーション「インターネットトランスポート・プロトコル」、XSIS028112、ゼロックス社、1981年12月。

   [4] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
       Sciences Institute, 28 August 1980.

[4] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が設けるUSC/情報、1980年8月28日。

   [5] Kastenholz, F., "SNMP Communications Services," RFC 1270,
       Clearpoint Research Corporation, October 1991.

[5]Kastenholz、F.、「SNMP情報提供サービス」、RFC1270、Clearpoint研究社、1991年10月。

   [6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
       Objects for Administration of SNMP Parties", RFC in preparation.

[6] 準備におけるMcCloghrie、K.、デーヴィン、J.、およびJ.ガルビン、「SNMP党の運営のための管理オブジェクトの定義」、RFC。

5.  Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Wormley & Bostock                                               [Page 4]

RFC 1298                     SNMP over IPX                 February 1992

IPX1992年2月の間のワァムリーとBostock[4ページ]RFC1298SNMP

6.  Authors' Addresses

6. 作者のアドレス

   Raymond Brett Wormley
   Novell, Inc.
   2180 Fortune Drive
   Mail Stop F5-91-2
   San Jose, CA 95131

F5-91-2サンノゼ、レイモンドブレットワァムリーノベルInc.2180財産ドライブメールStopカリフォルニア 95131

   Phone: 408 473 8208
   EMail: bwormley@novell.com

以下に電話をしてください。 8208年の408 473メール: bwormley@novell.com

   Steve Bostock
   Novell, Inc.
   2180 Fortune Drive
   Mail Stop F5-91-2
   San Jose, CA 95131

F5-91-2サンノゼ、スティーブBostockノベルInc.2180財産ドライブメールStopカリフォルニア 95131

   Phone: 408 473 8203
   EMail: steveb@novell.com

以下に電話をしてください。 8203年の408 473メール: steveb@novell.com

Wormley & Bostock                                               [Page 5]

ワァムリーとBostock[5ページ]