RFC1227 日本語訳

1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. (Format: TXT=25868 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                            M. Rose
Request for Comments: 1227       Performance Systems International, Inc.
                                                                May 1991

コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: Inc.1991年5月の国際の1227個の言語運用機構

                       SNMP MUX Protocol and MIB

SNMP多重化装置プロトコルとMIB

Status of this Memo

このMemoの状態

   This memo suggests a mechanism by which a user process may associate
   itself with the local SNMP agent on a host, in order to implement
   portions of the MIB.  This mechanism would be local to the host.

このメモはユーザ・プロセスがホストの上の地元のSNMPエージェントと共に加盟するかもしれないメカニズムを示します、MIBの一部を実装するために。 ホストにとって、このメカニズムはローカルでしょう。

   This is an Experimental Protocol for the Internet community.
   Discussion and suggestions for improvement are requested.  Please
   refer to the current edition of the "IAB Official Protocol Standards"
   for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

これはインターネットコミュニティのためのExperimentalプロトコルです。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Table of Contents

目次

   1. Introduction ..........................................    1
   2. Architecture ..........................................    2
   3. Protocol ..............................................    3
   3.1 Tricky Things ........................................    3
   3.1.1 Registration .......................................    4
   3.1.2 Removing Registration ..............................    4
   3.1.3 Atomic Sets ........................................    4
   3.1.4 Variables in Requests ..............................    5
   3.1.5 Request-ID .........................................    5
   3.1.6 The powerful get-next operator .....................    5
   3.2 Protocol Data Units ..................................    6
   3.3 Mappings on Transport Service ........................    8
   3.3.1 Mapping onto the TCP ...............................    8
   4. MIB for the SMUX ......................................    9
   5. Acknowledgements ......................................   12
   6. References ............................................   12
   7. Security Considerations................................   13
   8. Author's Address.......................................   13

1. 序論… 1 2. アーキテクチャ… 2 3. 議定書を作ってください… 3 3.1 トリッキーThings… 3 3.1 .1登録… 4 3.1 .2 登録を取り除きます… 4 3.1 .3 原子セット… 4 3.1 要求における.4の変数… 5 3.1 .5要求ID… 5 3.1 .6 強力な気付いているオペレータ… 5 3.2 データ単位について議定書の中で述べてください… 6 輸送サービスに関する3.3のマッピング… 8 3.3 .1 TCPに写像します。 8 4. SMUXのためのMIB… 9 5. 承認… 12 6. 参照… 12 7. セキュリティ問題… 13 8. 作者のアドレス… 13

1.  Introduction

1. 序論

   On typical kernel/user systems, an agent speaking the SNMP [1] is
   often implemented as a user-process, that reads kernel variables in
   order to realize the Internet-standard MIB [2].  This approach works
   fine as long as all of the information needed by the SNMP agent
   resides in either the kernel or in stable storage (i.e., files).
   However, when other user-processes are employed to implement other

典型的なカーネル/ユーザシステムの上では、SNMP[1]を話しているエージェントはユーザ・プロセスとしてしばしば実装されます、とそれがインターネット標準MIB[2]がわかるためにカーネル変数を読みます。 SNMPエージェントによって必要とされた情報のすべてがカーネルか安定貯蔵(すなわち、ファイル)に住んでいる限り、このアプローチはきめ細かに働いています。 しかしながら、他ときに、ユーザ・プロセスは道具他に使われます。

Rose                                                            [Page 1]

RFC 1227                          SMUX                          May 1991

[1ページ]RFC1227SMUX1991年5月に、上昇しました。

   network services, such as routing protocols, communication between
   the SNMP agent and other processes is problematic.

ルーティング・プロトコルなどのサービスをネットワークでつないでください、そして、SNMPエージェントと他のプロセスとのコミュニケーションは問題が多いです。

   In order to solve this problem, a new protocol, the SNMP multiplexing
   (SMUX) protocol is introduced.  When a user-process, termed a SMUX
   peer, wishes to export a MIB module, it initiates a SMUX association
   to the local SNMP agent, registers itself, and (later) fields
   management operations for objects in the MIB module.

この問題、新しいプロトコルを解決するために、SNMPマルチプレクシング(SMUX)プロトコルは紹介されます。 SMUX同輩はMIBモジュールをエクスポートするという願望、(後で)ユーザ・プロセスであるときに、地元のSNMPエージェントにSMUX協会を開始して、それ自体を登録して、MIBモジュールでオブジェクトのための管理操作をさばくと呼びました。

   Carrying this approach to its fullest, it is possible to generalize
   the SNMP agent so that it knows about only the SNMP group of the
   Internet-standard MIB.  All other portions of the Internet-standard
   MIB can be implemented by another process.  This is quite useful, for
   example, when a computer manufacturer wishes to provide SNMP access
   for its operating system in binary form.

十二分にこのアプローチを運んで、SNMPエージェントを一般化するのが可能であるので、それはインターネット標準MIBのSNMPグループだけに関して知っています。 別のプロセスはインターネット標準MIBの他のすべての一部を実装することができます。 コンピュータメーカーがオペレーティングシステムのために二部形式でアクセスをSNMPに供給したがっているとき、例えば、これはかなり役に立ちます。

   In addition to defining the SMUX protocol, this document defines a
   MIB for the SMUX.  Obviously, this MIB module must also be
   implemented in the local SNMP agent.

SMUXプロトコルを定義することに加えて、このドキュメントはSMUXのためにMIBを定義します。 また、明らかに、地元のSNMPエージェントでこのMIBモジュールを実装しなければなりません。

2.  Architecture

2. アーキテクチャ

   There are two approaches that can be taken when trying to integrate
   arbitrary MIB modules with the SNMP agent: request-response and
   cache-ahead.

任意のMIBモジュールをSNMPエージェントと統合しようとするとき取ることができる2つのアプローチがあります: 要求応答と先のキャッシュ。

   The request-response model simply propagates the SNMP requests
   received by the SNMP agent to the user process which exported the MIB
   module.  The SMUX peer then performs the operation and returns a
   response.  In turn, the SNMP agent propagates this response back to
   the network management station.  The request-response model is said
   to be agent-driven since, after registration, the SNMP agent
   initiates all transactions.

要求応答モデルは単にSNMPエージェントによって受け取られたSNMP要求をMIBモジュールをエクスポートしたユーザ・プロセスに伝播します。 SMUX同輩は、次に、操作を実行して、応答を返します。 順番に、SNMPエージェントはネットワークマネージメントステーションへのこの応答を伝播します。 SNMPエージェントが登録の後にすべてのトランザクションを開始するので、要求応答モデルはエージェントが駆動であると言われています。

   The cache-ahead model requires that the SMUX peer, after
   registration, periodically updates the SNMP agent with the subtree
   for the MIB module which has been registered.  The SNMP agent, upon
   receiving an SNMP request for information retrieval, locally performs
   the operation, and returns a response to the network management
   station.  (SNMP set requests are given immediately to the SMUX peer.)
   The cache-ahead model is said to be peer-driven since, after
   registration, the SMUX peer initiates all transactions.

先のキャッシュモデルは、SMUX同輩が登録の後に登録されたMIBモジュールのために定期的に下位木でSNMPエージェントをアップデートするのを必要とします。 SNMPエージェントは、局所的に情報検索を求めるSNMP要求を受け取るのに操作を実行して、ネットワークマネージメントステーションへの応答を返します。 (SNMPセット要求をすぐSMUX同輩に与えます。) SMUX同輩が登録の後にすべてのトランザクションを開始するので、先のキャッシュモデルは同輩が駆動であると言われています。

   There are advantages and disadvantages to both approaches.  As such,
   the architecture envisioned supports both models in the following
   fashion: the protocol between the SNMP agent and the SMUX peer is
   based on the request-response model.  However, the SMUX peer, may
   itself be a user-process which employs the cache-ahead model with

両方のアプローチへの利点と難点があります。 そういうものとして、思い描かれたアーキテクチャは以下のファッションで両方のモデルをサポートします: SNMPエージェントとSMUX同輩の間のプロトコルは要求応答モデルに基づいています。 しかしながら、SMUXがじっと見る、それ自体、先のキャッシュがそれの雇用でモデル化するaユーザ・プロセスになるかもしれなくなってください。

Rose                                                            [Page 2]

RFC 1227                          SMUX                          May 1991

[2ページ]RFC1227SMUX1991年5月に、上昇しました。

   other user-processes.

他のユーザ・プロセス。

   Obviously, the SMUX peer which employs the cache-ahead model acts as
   a "firewall" for those user-processes which actually implement the
   managed objects in the given MIB module.

明らかに、先のキャッシュモデルを雇うSMUX同輩は実際に与えられたMIBモジュールで管理オブジェクトを実装するそれらのユーザ・プロセスのための「ファイアウォール」として務めます。

   Note that this document describes only the SMUX protocol, for the
   request-response model.  Each SMUX peer is free to define a cache-
   ahead protocol specific for the application at hand.

このドキュメントが要求応答モデルのためにSMUXプロトコルだけについて説明することに注意してください。 それぞれのSMUX同輩は自由に手元のアプリケーションに、特定の先のキャッシュのプロトコルを定義できます。

3.  Protocol

3. プロトコル

   The SMUX protocol is simple: the SNMP agent listens for incoming
   connections.  Upon establishing a connection, the SMUX peer issues an
   OpenPDU to initialize the SMUX association.  If the SNMP agent
   declines the association, it issues a closePDU and closes the
   connection.  If the SNMP agent accepts the association, no response
   is issued by the SNMP agent.

SMUXプロトコルは簡単です: SNMPエージェントは接続要求の聞こうとします。 取引関係を築くと、SMUX同輩は、SMUX協会を初期化するためにOpenPDUを発行します。 SNMPエージェントが協会を衰退させるなら、それは、closePDUを発行して、接続を終えます。 SNMPエージェントが協会を受け入れるなら、応答は全くSNMPエージェントによって発行されません。

   For each subtree defined in a MIB module that the SMUX peer wishes to
   register (or unregister), the SMUX peer issues a RReqPDU.  When the
   SNMP agent receives such a PDU, it issues a corresponding RRspPDU.
   The SNMP agent returns RRspPDUs in the same order as the RReqPDUs
   were received.

SMUX同輩が登録したがっているMIBモジュール(または、「非-レジスタ」)で定義された各下位木のために、SMUX同輩はRReqPDUを発行します。 SNMPエージェントがそのようなPDUを受け取るとき、それは対応するRRspPDUを発行します。 SNMPエージェントはRReqPDUsを受け取ったように同次でRRspPDUsを返します。

   When the SMUX peer wishes to issue a trap, it issues an SNMP Trap-
   PDU.  When the SNMP agent receives such a PDU, it propagates this to
   the network management stations that it is configured to send traps
   to.

SMUX同輩が罠を発行したがっているとき、それはSNMP Trap- PDUを発行します。 SNMPエージェントがそのようなPDUを受け取るとき、それは罠を送るのが構成されているネットワークマネージメントステーションにこれを伝播します。

   When the SNMP agent receives an SNMP GetRequest-PDU, GetNextRequest-
   PDU, or SetRequest-PDU which includes one or more variable-bindings
   within a subtree registered by a SMUX peer, the SNMP agent sends an
   equivalent SNMP PDU containing only those variables within the
   subtree registered by that SMUX peer.  When the SMUX peer receives
   such a PDU, it applies the indicated operation and issues a
   corresponding SNMP GetResponse-PDU.  The SNMP agent then correlates
   this result and propagates the resulting GetResponse-PDU to the
   network management station.

SNMPエージェントがSMUX同輩によって登録された下位木の中に1つ以上の変項束縛を含んでいるSNMP GetRequest-PDU、GetNextRequest- PDU、またはSetRequest-PDUを受け取るとき、SNMPエージェントはそのSMUX同輩によって登録された下位木の中にそれらの変数だけを含む同等なSNMP PDUを送ります。 SMUX同輩がそのようなPDUを受け取るとき、それは、示された操作を適用して、対応するSNMP GetResponse-PDUを発行します。 SNMPエージェントは、次に、この結果を関連させて、結果として起こるGetResponse-PDUをネットワークマネージメントステーションに伝播します。

   When either the SNMP agent or the SMUX peer wishes to release the
   SMUX association, the ClosePDU is issued, the connection is closed,
   and all subtree registrations for that association are released.

SNMPエージェントかSMUX同輩のどちらかがSMUX協会をリリースしたがっているとき、ClosePDUは発行されます、そして、接続は終えられます、そして、その協会のためのすべての下位木登録証明書がリリースされます。

3.1.  Tricky Things

3.1. トリッキーThings

   Although straight-forward, there are a few nuances.

簡単ですが、いくつかのニュアンスがあります。

Rose                                                            [Page 3]

RFC 1227                          SMUX                          May 1991

[3ページ]RFC1227SMUX1991年5月に、上昇しました。

3.1.1.  Registration

3.1.1. 登録

   Associated with each registration is an integer priority, from 0 to
   (2^31)-1.  The lower the value, the higher the priority.

0〜(2^31)まで各登録に関連しているのは、-1に整数優先です。 値が低ければ低いほど、優先度は、より高いです。

   Multiple SMUX peers may register the same subtree.  However, they
   must do so at different priorities (i.e., a subtree and a priority
   uniquely identifies a SMUX peer).  As such, if a SMUX peer wishes to
   register a subtree at a priority which is already taken, the SNMP
   agent repeatedly increments the integer value until an unused
   priority is found.

複数のSMUX同輩が同じ下位木を登録するかもしれません。 しかしながら、彼らは異なったプライオリティでそうしなければなりません(すなわち、下位木と優先は唯一SMUX同輩を特定します)。 そういうものとして、SMUX同輩が既にかかる優先で下位木を登録したいなら、未使用の優先が見つけられるまで、SNMPエージェントは繰り返して整数値を増加します。

   When registering a subtree, the special priority -1 may be used,
   which selects the highest available priority.

下位木を登録するとき、特別な優先権-1(最も高い利用可能な優先度を選択します)は使用されるかもしれません。

   Of course, the SNMP agent may select an arbitrarily worse priority
   for a SMUX peer, based on local (configuration) information.

もちろん、SNMPエージェントはローカルの(構成)情報に基づいてSMUX同輩のために任意により悪い優先を選択するかもしれません。

   Note that when a subtree is registered, the SMUX peer with the
   highest registration priority is exclusively consulted for all
   operations on that subtree.  Further note that SNMP agents must
   enforce the "subtree mounting effect", which hides the registrations
   by other SMUX peers of objects within the subtree.  For example, if a
   SMUX peer registered "sysDescr", and later another SMUX peer
   registered "system" (which scopes "sysDescr"), then all requests for
   "sysDescr" would be given to the latter SMUX peer.

下位木が登録されているとき、最も高い登録優先度をもっているSMUX同輩がその下位木におけるすべての操作のために排他的に相談されることに注意してください。 SNMPエージェントが下位木の中にオブジェクトの他のSMUX同輩による登録証明書を隠す「下位木の上がっている効果」を実施しなければならないことにさらに注意してください。 例えば、SMUX同輩が"sysDescr"を登録して、別のSMUX同輩が後で「システム」("sysDescr"を見る)を登録するなら、"sysDescr"を求めるすべての要求を後者のSMUX同輩に与えるでしょうに。

   An SNMP agent should disallow any attempt to register above, at, or
   below, the SNMP and SMUX subtrees of the MIB.  Other subtrees may be
   disallowed as an implementation-specific option.

SNMPエージェントは下位木の上と、そして、下位木において、または、MIBのSNMPとSMUX下位木の下で登録するどんな試みも禁じるべきです。 他の下位木は実装特有のオプションとして禁じられるかもしれません。

3.1.2.  Removing Registration

3.1.2. 登録を取り除きます。

   A SMUX peer may remove registrations for only those subtrees which it
   has registered.  If the priority given in the RReqPDU is -1, then the
   registration of highest priority is selected for deletion.
   Otherwise, only that registration with the precise priority is
   selected.

SMUX同輩はそれが登録したそれらの下位木だけのための登録証明書を取り除くかもしれません。 RReqPDUで与えられた優先が-1であるなら、最優先の登録は削除のために選択されます。 正確な優先権があるその登録だけが選択されます。

3.1.3.  Atomic Sets

3.1.3. 原子セット

   A simple two-phase commit protocol is used between the SNMP agent and
   the SMUX peers.  When an SNMP SetRequest-PDU is received, the SNMP
   agent determines which SMUX peers will participate in the
   transaction.  For each of these peers, at least one SNMP SetRequest-
   PDU is sent, with only those variables of interest to that peer.

簡単な二相はSNMPエージェントとSMUX同輩の間で使用されるプロトコルを遂行します。 SNMP SetRequest-PDUが受け取られているとき、SNMPエージェントは、どのSMUX同輩がトランザクションに参加するかを決心しています。 これらの同輩各人に関しては、少なくとも1SNMP SetRequest- PDUを送ります、その同輩にとって、興味深いそれらの変数だけで。

   Each SMUX peer must either accept or refuse the set operation,

それぞれのSMUX同輩は、集合演算を受け入れなければならないか、または拒否しなければなりません。

Rose                                                            [Page 4]

RFC 1227                          SMUX                          May 1991

[4ページ]RFC1227SMUX1991年5月に、上昇しました。

   without actually performing the operation.  If the peer opts to
   accept, it sends back an SNMP GetResponse-PDU with an error-status of
   noError(0); otherwise, if the peer refuses to perform the operation,
   then an SNMP GetResponse-PDU is returned with a non-zero error-
   status.

実際に操作を実行しないで。 同輩が受け入れるために選ぶなら、noError(0)のエラー状況でSNMP GetResponse-PDUを返送します。 さもなければ、同輩が、操作を実行するのを拒否するなら、a非ゼロ誤り状態と共にSNMP GetResponse-PDUを返します。

   The SNMP agent examines all of the responses.  If at least one SMUX
   peer refused the operation, then a SMUX SOutPDU is sent to each SMUX
   peer, with value rollback, telling the SMUX peer to discard any
   knowledge of the requested operation.

SNMPエージェントは応答のすべてを調べます。 少なくとも1人のSMUX同輩が操作を拒否したなら、それぞれのSMUX同輩にSMUX SOutPDUを送ります、値のロールバックで、要求された操作に関するあらゆる知識を捨てるようにSMUX同輩に言って。

   Otherwise if all SMUX peers accepted the operation, then a SMUX
   SOutPDU is sent to each SMUX peer, with value commit, telling the
   SMUX peer to perform the operation.

さもなければ、すべてのSMUX同輩が操作を受け入れたなら、それぞれのSMUX同輩にSMUX SOutPDUを送って、値で、公約してください、操作を実行するようにSMUX同輩に言って。

   In either case, the SMUX peer does not generate a response to the
   SMUX SOutPDU.

どちらの場合ではも、SMUX同輩はSMUX SOutPDUへの応答を生成しません。

3.1.4.  Variables in Requests

3.1.4. 要求における変数

   When constructing an SNMP GetRequest-PDU or GetNextRequest-PDU for a
   SMUX peer, the SNMP agent may send one, or more than one variable in
   a single request.  In all cases, the SNMP agent should process each
   variable sequentially, and block accordingly when a SMUX peer is
   contacted.

SMUX同輩のためにSNMP GetRequest-PDUかGetNextRequest-PDUを組み立てるとき、SNMPエージェントはただ一つの要求で1、または1つ以上の変数を送るかもしれません。 すべての場合では、SNMPエージェントは各変数を連続して処理するべきです、そして、それに従って、いつを妨げてくださいか。SMUX同輩は連絡されます。

3.1.5.  Request-ID

3.1.5. 要求ID

   When the SNMP agent constructs an SNMP GetRequest-PDU,
   GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the
   request_id field of the SNMP takes a special meaning: if an SNMP
   agent generates multiple PDUs for a SMUX peer, upon receipt of a
   single PDU from the network management station, then the request_id
   field of the PDUs sent to the SMUX peer must take the same value
   (which need bear no relationship to the value of the request_id field
   of the PDU originally received by the SNMP agent.)

SNMPエージェントがSMUX同輩のためにSNMP GetRequest-PDU、GetNextRequest-PDU、またはSetRequest-PDUを組み立てるとき、SNMPの要求_イド分野は特別な意味を取ります: SNMPエージェントがネットワークマネージメントステーションからの独身のPDUを受け取り次第SMUX同輩のために複数のPDUsを生成するなら、SMUX同輩に送られたPDUsの要求_イド分野は同じ値を取らなければなりません。(どれが元々PDUの要求_イド分野の値との関係に全く堪える必要はないかはSNMPエージェントのそばで受信されました。)

3.1.6.  The powerful get-next operator

3.1.6. 強力な気付いているオペレータ

   Each SMUX peer acts as though it contains the entire MIB when
   processing a SNMP GetNext-PDU from the SNMP agent.  This means that
   the SNMP agent must check each variable returned in the SNMP
   GetResponse-PDU generated by the SMUX peer to ensure that each
   variable is still within the same registered subtree as caused the
   SNMP GetNext-PDU to be sent to that peer.  For each variable which is
   not, the SNMP agent must include it in a SNMP GetNext-PDU to the peer
   for the succeeding registered subtree, until responses are available
   for all variables within their expected registered subtree.

SNMPエージェントからSNMP GetNext-PDUを処理するとき、まるで全体のMIBを含むかのようにそれぞれのSMUX同輩は行動します。 これは、SNMPエージェントがまだSNMP GetNext-PDUがその同輩に送るために引き起こされるのと同じ登録された下位木の中に各変数があるのを保証するためにSMUX同輩によって生成されたSNMP GetResponse-PDUで返された各変数をチェックしなければならないことを意味します。 そうしない各変数のために、SNMPエージェントはSNMP GetNext-PDUで続く登録された下位木のための同輩にそれを入れなければなりません、応答がそれらの予想された登録された下位木の中ですべての変数に利用可能になるまで。

Rose                                                            [Page 5]

RFC 1227                          SMUX                          May 1991

[5ページ]RFC1227SMUX1991年5月に、上昇しました。

3.2.  Protocol Data Units

3.2. プロトコルデータ単位

   The SMUX protocol data units are defined using Abstract Syntax
   Notation One (ASN.1) [3]:

SMUXプロトコルデータ単位は抽象的なSyntax Notation One(ASN.1)[3]を使用することで定義されます:

   SMUX DEFINITIONS ::= BEGIN

SMUX定義:、:= 始まってください。

   IMPORTS
           DisplayString, ObjectName
                   FROM RFC1155-SMI

RFC1155-SMIからDisplayString、ObjectNameをインポートします。

           PDUs
                   FROM RFC1157-SNMP;

RFC1157-SNMPからのPDUs。

   -- tags for SMUX-specific PDUs are application-wide to
   -- avoid conflict with tags for current (and future)
   -- SNMP-generic PDUs

-- SMUX特有のPDUsのためのタグがアプリケーション全体である、--電流(そして、未来)のためにタグとの闘争を避けてください--、SNMP-ジェネリックPDUs

   SMUX-PDUs ::=
       CHOICE {
           open            -- SMUX peer uses
               OpenPDU,    -- immediately after TCP open

SMUX-PDUs:、:= CHOICE、開いてください--SMUX同輩はTCP戸外直後OpenPDUを使用します。

           close           -- either uses immediately before TCP close
               ClosePDU,

閉じてください--どちらかがTCPの直前近いClosePDUを使用します。

           registerRequest -- SMUX peer uses
               RReqPDU,

最もregisterRequestに、SMUX同輩はRReqPDUを使用します。

           registerResponse -- SNMP agent uses
               RRspPDU,

registerResponse--SNMPエージェントはRRspPDUを使用します。

               PDUs,       -- note that roles are reversed:
                           --   SNMP agent does get/get-next/set
                           --   SMUX peer does get-response/trap

PDUs--役割が逆にされることに注意してください: -- SNMPエージェントは、/セットを手に入れるか、または-次に、手に入れます--SMUX同輩は応答を得ている/罠をします。

           commitOrRollback -- SNMP agent uses
               SOutPDU
      }

commitOrRollback、--SNMPエージェントがSOutPDUを使用する

   -- open PDU
   -- currently only simple authentication

-- 開いているPDU--現在の簡易認証だけ

   OpenPDU ::=
       CHOICE {
          simple

OpenPDU:、:= CHOICE、簡単

Rose                                                            [Page 6]

RFC 1227                          SMUX                          May 1991

[6ページ]RFC1227SMUX1991年5月に、上昇しました。

              SimpleOpen
       }

SimpleOpen

   SimpleOpen ::=
       [APPLICATION 0] IMPLICIT
           SEQUENCE {
               version     -- of SMUX protocol
                   INTEGER {
                       version-1(0)
                   },

SimpleOpen:、:= [APPLICATION0]IMPLICIT SEQUENCE、バージョン--SMUXでは、INTEGERバージョン-1(0)について議定書の中で述べてください。

               identity    -- of SMUX peer, authoritative
                   OBJECT IDENTIFIER,

SMUX同輩、正式のOBJECT IDENTIFIERのアイデンティティ

               description -- of SMUX peer, implementation-specific
                   DisplayString,

SMUX同輩、実装特有のDisplayStringの記述

               password    -- zero length indicates no authentication
                   OCTET STRING
           }

パスワード--長さのゼロを合わせるのは認証がないOCTET STRINGを示します。

   -- close PDU

-- PDUを閉じてください。

   ClosePDU ::=
       [APPLICATION 1] IMPLICIT
           INTEGER {
               goingDown(0),
               unsupportedVersion(1),
               packetFormat(2),
               protocolError(3),
               internalError(4),
               authenticationFailure(5)
           }

ClosePDU:、:= [アプリケーション1] 暗黙の整数goingDown(0)、unsupportedVersion(1)、packetFormat(2)、protocolError(3)、internalError(4)、authenticationFailure(5)

   -- insert PDU

-- PDUを挿入してください。

   RReqPDU ::=
       [APPLICATION 2] IMPLICIT
           SEQUENCE {
               subtree
                   ObjectName,

RReqPDU:、:= [APPLICATION2]IMPLICIT SEQUENCE、下位木ObjectName

               priority    -- the lower the better, "-1" means default
                   INTEGER (-1..2147483647),

優先権--より低く「-1インチはデフォルト整数(-1 .2147483647)を意味するほうがよいです」。

               operation

操作

Rose                                                            [Page 7]

RFC 1227                          SMUX                          May 1991

[7ページ]RFC1227SMUX1991年5月に、上昇しました。

                   INTEGER {
                       delete(0),    -- remove registration
                       readOnly(1),  -- add registration, objects are RO
                       readWrite(2)  --   .., objects are RW
                   }
           }

INTEGER、(0)を削除してください--登録readOnly(1)を取り外してください、(登録、オブジェクトがRO readWrite(2)であると言い足してください)オブジェクトはRWです。

   RRspPDU ::=
       [APPLICATION 3] IMPLICIT
           INTEGER {
               failure(-1)

RRspPDU:、:= [APPLICATION3]IMPLICIT INTEGER、失敗(-1)

              -- on success the non-negative priority is returned
           }

-- 成功では、非否定的な優先権は返されます。

   SOutPDU ::=
       [APPLICATION 4] IMPLICIT
           INTEGER {
               commit(0),
               rollback(1)
           }

SOutPDU:、:= [アプリケーション4] 暗黙の整数(0)、ロールバック(1)を遂行してください。

   END

終わり

3.3.  Mappings on Transport Service

3.3. 輸送サービスに関するマッピング

   The SMUX protocol may be mapped onto any CO-mode transport service.
   At present, only one such mapping is defined.

SMUXプロトコルはどんなCO-モード輸送サービスにも写像されるかもしれません。 現在のところ、そのようなマッピングの1つだけが定義されます。

3.3.1.  Mapping onto the TCP

3.3.1. TCPへのマッピング

   When using the TCP to provide the transport-backing for the SMUX
   protocol, the SNMP agent listens on TCP port 199.

SMUXプロトコルのための輸送支援を提供するのにTCPを使用するとき、SNMPエージェントはTCPポート199の上で聴きます。

   Each SMUX PDU is serialized using the Basic Encoding Rules [4] and
   sent on the TCP.  As ASN.1 objects are self-delimiting when encoding
   using the BER, no packetization protocol is required.

各SMUX PDUをBasic Encoding Rules[4]を使用することで連載して、TCPに送ります。 BERを使用することでコード化するとき、ASN.1オブジェクトが自己に区切られているとき、どんなpacketizationプロトコルも必要ではありません。

Rose                                                            [Page 8]

RFC 1227                          SMUX                          May 1991

[8ページ]RFC1227SMUX1991年5月に、上昇しました。

4.  MIB for the SMUX

4. SMUXのためのMIB

   The MIB objects for the SMUX are implemented by the local SNMP agent:

SMUXのためのMIBオブジェクトは地元のSNMPエージェントによって実装されます:

          SMUX-MIB DEFINITIONS ::= BEGIN

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

          IMPORTS
                  enterprises
                          FROM RFC1155-SMI
                  OBJECT-TYPE
                          FROM RFC1212;

IMPORTS企業FROM RFC1155-SMI OBJECT-TYPE FROM RFC1212。

          unix    OBJECT IDENTIFIER ::= { enterprises 4 }

unix OBJECT IDENTIFIER:、:= 企業4

          smux    OBJECT IDENTIFIER ::= { unix 4 }

smux OBJECT IDENTIFIER:、:= unix4

          smuxPeerTable   OBJECT-TYPE
                  SYNTAX  SEQUENCE OF SmuxPeerEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                      "The SMUX peer table."
                  ::= { smux 1 }

「SMUX同輩はテーブルの上に置く」smuxPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF SmuxPeerEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 ::= smux1

          smuxPeerEntry   OBJECT-TYPE
                  SYNTAX  SmuxPeerEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                      "An entry in the SMUX peer table."
                  INDEX   { smuxPindex }
                  ::= { smuxPeerTable 1}

「SMUX同輩のエントリーはテーブルの上に置く」smuxPeerEntry OBJECT-TYPE SYNTAX SmuxPeerEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 smuxPindexに索引をつけてください:、:= smuxPeerTable1

          SmuxPeerEntry ::=
              SEQUENCE {
                  smuxPindex
                      INTEGER,
                  smuxPidentity
                      OBJECT IDENTIFIER,
                  smuxPdescription
                      DisplayString,
                  smuxPstatus
                      INTEGER
              }

SmuxPeerEntry:、:= 系列smuxPindex整数、smuxPidentityオブジェクト識別子、smuxPdescription DisplayString、smuxPstatus整数

          smuxPindex      OBJECT-TYPE
                  SYNTAX  INTEGER
                  ACCESS  read-only

smuxPindex OBJECT-TYPE SYNTAX INTEGER ACCESS書き込み禁止

Rose                                                            [Page 9]

RFC 1227                          SMUX                          May 1991

[9ページ]RFC1227SMUX1991年5月に、上昇しました。

                  STATUS  mandatory
                  DESCRIPTION
                      "An index which uniquely identifies a SMUX peer."
                  ::= { smuxPeerEntry 1 }

STATUSの義務的な記述、「唯一SMUX同輩を特定するインデックス。」 ::= smuxPeerEntry1

          smuxPidentity   OBJECT-TYPE
                  SYNTAX  OBJECT IDENTIFIER
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "The authoritative designation for a SMUX peer."
                  ::= { smuxPeerEntry 2 }

smuxPidentity OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESSの書き込み禁止のSTATUSの義務的な記述、「SMUX同輩にとって、正式の名称。」 ::= smuxPeerEntry2

          smuxPdescription OBJECT-TYPE
                  SYNTAX  DisplayString (SIZE (0..255))
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "A human-readable description of a SMUX peer."
                  ::= { smuxPeerEntry 3 }

smuxPdescription OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .255))のACCESSの書き込み禁止のSTATUSの義務的な記述、「SMUX同輩の人間読み込み可能な記述。」 ::= smuxPeerEntry3

          smuxPstatus     OBJECT-TYPE
                  SYNTAX  INTEGER { valid(1), invalid(2), connecting(3) }
                  ACCESS  read-write
                  STATUS  mandatory
                  DESCRIPTION
                      "The type of SMUX peer.

smuxPstatus OBJECT-TYPE SYNTAX INTEGER、有効な(1)、病人(2)、ACCESSがSTATUS義務的な記述を読書して書く接続(3)、「SMUXのタイプはじっと見ます」。

                      Setting this object to the value invalid(2) has
                      the effect of invaliding the corresponding entry
                      in the smuxPeerTable.  It is an implementation-
                      specific matter as to whether the agent removes an
                      invalidated entry from the table.  Accordingly,
                      management stations must be prepared to receive
                      tabular information from agents that correspond to
                      entries not currently in use.  Proper
                      interpretation of such entries requires
                      examination of the relative smuxPstatus object."
                  ::= { smuxPeerEntry 4 }

値の病人(2)にこのオブジェクトを設定するのにおいて、対応するエントリーがsmuxPeerTableで無効であるという効果があります。 それはエージェントがテーブルから無効にされたエントリーを取り除くかどうかに関する実装の特定の問題です。 それに従って、現在使用中でないエントリーに文通するエージェントから表情報を受け取るように管理局を準備しなければなりません。 「そのようなエントリーの適切な解釈は相対的なsmuxPstatusオブジェクトの試験を必要とします。」 ::= smuxPeerEntry4

          smuxTreeTable   OBJECT-TYPE
                  SYNTAX  SEQUENCE OF SmuxTreeEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                      "The SMUX tree table."
                  ::= { smux 2 }

「SMUX木はテーブルの上に置く」smuxTreeTable OBJECT-TYPE SYNTAX SEQUENCE OF SmuxTreeEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 ::= smux2

Rose                                                           [Page 10]

RFC 1227                          SMUX                          May 1991

[10ページ]RFC1227SMUX1991年5月に、上昇しました。

          smuxTreeEntry   OBJECT-TYPE
                  SYNTAX  SmuxTreeEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                      "An entry in the SMUX tree table."
                  INDEX   { smuxTsubtree, smuxTpriority }
                  ::= { smuxTreeTable 1}

「SMUX木のエントリーはテーブルの上に置く」smuxTreeEntry OBJECT-TYPE SYNTAX SmuxTreeEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 smuxTsubtree、smuxTpriorityに索引をつけてください:、:= smuxTreeTable1

          SmuxTreeEntry ::=
              SEQUENCE {
                  smuxTsubtree
                      OBJECT IDENTIFIER,
                  smuxTpriority
                      INTEGER,
                  smuxTindex
                      INTEGER,
                  smuxTstatus
                      INTEGER
              }

SmuxTreeEntry:、:= 系列smuxTsubtreeオブジェクト識別子、smuxTpriority整数、smuxTindex整数、smuxTstatus整数

          smuxTsubtree    OBJECT-TYPE
                  SYNTAX  OBJECT IDENTIFIER
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "The MIB subtree being exported by a SMUX peer."
                  ::= { smuxTreeEntry 1 }

smuxTsubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESSの書き込み禁止のSTATUSの義務的な記述、「SMUX同輩によってエクスポートされるMIB下位木。」 ::= smuxTreeEntry1

          smuxTpriority OBJECT-TYPE
                  SYNTAX  INTEGER (0..'07fffffff'h)
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "The SMUX peer's priority when exporting the MIB
                      subtree."
                  ::= { smuxTreeEntry 2 }

smuxTpriority OBJECT-TYPE SYNTAX INTEGER(0'07fffffff'h)のACCESSの書き込み禁止のSTATUSの義務的な記述、「SMUX同輩の優先権、MIB下位木をエクスポートする、」、' ::= smuxTreeEntry2

          smuxTindex OBJECT-TYPE
                  SYNTAX  INTEGER
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "The SMUX peer's identity."
                  ::= { smuxTreeEntry 3 }

smuxTindex OBJECT-TYPE SYNTAX INTEGER ACCESSの書き込み禁止のSTATUSの義務的な記述、「SMUX同輩のアイデンティティ。」 ::= smuxTreeEntry3

          smuxTstatus     OBJECT-TYPE
                  SYNTAX  INTEGER { valid(1), invalid(2) }

smuxTstatusオブジェクト・タイプ構文整数有効な(1)、病人(2)

Rose                                                           [Page 11]

RFC 1227                          SMUX                          May 1991

[11ページ]RFC1227SMUX1991年5月に、上昇しました。

                  ACCESS  read-write
                  STATUS  mandatory
                  DESCRIPTION
                      "The type of SMUX tree.

ACCESSは「SMUXのタイプは木に登ること」をSTATUSの義務的な記述に読書して書きます。

                      Setting this object to the value invalid(2) has
                      the effect of invaliding the corresponding entry
                      in the smuxTreeTable.  It is an implementation-
                      specific matter as to whether the agent removes an
                      invalidated entry from the table.  Accordingly,
                      management stations must be prepared to receive
                      tabular information from agents that correspond to
                      entries not currently in use.  Proper
                      interpretation of such entries requires
                      examination of the relative smuxTstatus object."
                  ::= { smuxTreeEntry 4 }

値の病人(2)にこのオブジェクトを設定するのにおいて、対応するエントリーがsmuxTreeTableで無効であるという効果があります。 それはエージェントがテーブルから無効にされたエントリーを取り除くかどうかに関する実装の特定の問題です。 それに従って、現在使用中でないエントリーに文通するエージェントから表情報を受け取るように管理局を準備しなければなりません。 「そのようなエントリーの適切な解釈は相対的なsmuxTstatusオブジェクトの試験を必要とします。」 ::= smuxTreeEntry4

          END

終わり

5.  Acknowledgements

5. 承認

   SMUX was designed one afternoon by these people:

SMUXはある午後の間、これらの人々によって設計されました:

               Jeffrey S. Case, UTK-CS
               James R. Davin, MIT-LCS
               Mark S. Fedor, PSI
               Jeffrey C. Honig, Cornell
               Louie A. Mamakos, UMD
               Michael G. Petry, UMD
               Yakov Rekhter, IBM
               Marshall T. Rose, PSI

ジェフリーS.事件、UTK-Csジェームス・R.デーヴィン、MIT-LCSマークS.ヒョードル、ψジェフリー・C.ホニッグ、コーネルルイA.Mamakos、UMDマイケルG.Petry、UMDヤコフRekhter、IBMのマーシャルT.は上昇しました、psi

6.  References

6. 参照

   [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

[1] SNMPが研究するケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、RFC1157、国際言語運用機構、国際言語運用機構(MITコンピュータサイエンス研究所)は1990がそうするかもしれません。

   [2] McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based Internets", RFC 1156,
       Performance Systems International and Hughes LAN Systems, May
       1990.

[2] 「TCP/IPベースのインターネットのネットワークマネージメントのための管理情報ベース」(RFC1156、国際言語運用機構、およびヒューズLANシステム)は、McCloghrie K.、およびM.は上昇して、1990がそうするかもしれません。

   [3] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization, International
       Standard 8824, December 1987.

[3] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構国際規格8824(1987年12月)の仕様。

Rose                                                           [Page 12]

RFC 1227                          SMUX                          May 1991

[12ページ]RFC1227SMUX1991年5月に、上昇しました。

   [4] Information processing systems - Open Systems Interconnection -
       Specification of Basic Encoding Rules for Abstract Notation One
       (ASN.1), International Organization for Standardization,
       International Standard 8825, December 1987.

[4] 情報処理システム--オープン・システム・インターコネクション--抽象的なNotation One(ASN.1)、国際標準化機構国際規格8825(1987年12月)のためのBasic Encoding Rulesの仕様。

   [5] Rose, M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based Internets", RFC 1155,
       Performance Systems International and Hughes LAN Systems, May
       1990.

[5] ローズ、M.、K.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」、RFC1155、国際言語運用機構、およびヒューズLANシステム(1990年5月)。

7. Security Considerations

7. セキュリティ問題

   Security issues are not discussed in this memo.

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

8. Author's Address

8. 作者のアドレス

   Marshall T. Rose
   Performance Systems International, Inc.
   5201 Great America Parkway
   Suite 3106
   Santa Clara, CA  95054

3106サンタクララ、マーシャルT.バラ言語運用機構国際Inc.5201グレート・アメリカ公園道路Suiteカリフォルニア 95054

   Phone: +1 408 562 6222

以下に電話をしてください。 +1 408 562 6222

   EMail: mrose@psi.com
   X.500:  rose, psi, us

メール: mrose@psi.com X.500: バラ、psi、私たち

Rose                                                           [Page 13]

上昇しました。[13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DATEDIFF関数 日付の差を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る