RFC1095 日本語訳
1095 Common Management Information Services and Protocol over TCP/IP(CMOT). U.S. Warrier, L. Besaw. April 1 1989. (Format: TXT=157506 bytes) (Obsoleted by RFC1189) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group U. Warrier
Request for Comments: 1095 Unisys Corporation
L. Besaw
Hewlett-Packard
April 1989
Warrierがコメントのために要求するワーキンググループU.をネットワークでつないでください: 1095 ユニシス社のL.Besawヒューレット・パッカード1989年4月
The Common Management Information Services and Protocol over TCP/IP
(CMOT)
TCP/IPの上の共通管理情報サービスとプロトコル(CMOT)
Table of Contents
目次
1. Status of this Memo ............................................ 3 2. Introduction ................................................... 4 Part I: Concepts and Models ....................................... 7 3. The OSI Management Framework ................................... 7 3.1. Architectural Overview ....................................... 7 3.2. Management Models ............................................ 8 3.2.1. The Organizational Model ................................... 8 3.2.2. The Functional Model ....................................... 8 3.2.3. The Information Model ...................................... 9 3.3. ISO Application Protocols .................................... 9 3.3.1. ACSE ....................................................... 10 3.3.2. ROSE ....................................................... 10 3.3.3. CMISE ...................................................... 10 3.3.3.1. Management Association Services .......................... 11 3.3.3.2. Management Notification Services ......................... 12 3.3.3.3. Management Operation Services ............................ 12 4. The CMOT Architecture .......................................... 13 4.1. Management Models ............................................ 13 4.1.1. The Organizational Model ................................... 13 4.1.2. The Functional Model ....................................... 14 4.1.3. The Information Model ...................................... 14 4.2. Protocol Architecture ........................................ 14 4.2.1 The Lightweight Presentation Layer .......................... 15 4.2.2 The Quality of Transport Service ............................ 16 4.3. Proxy Management ............................................. 17 4.4. Directory Service ............................................ 18 5. Management Information ......................................... 18 5.1. The Structure of Management Information ...................... 19 5.1.1. The ISO SMI ................................................ 19 5.1.1.1. Managed Objects and Attributes ........................... 19 5.1.1.2. Management Information Hierarchies ....................... 20 5.1.1.2.1 The Registration Hierarchy .............................. 20 5.1.1.2.2. The Containment Hierarchy .............................. 20 5.1.1.2.3. The Inheritance Hierarchy .............................. 22 5.1.2. The Internet SMI ........................................... 22 5.2. The Management Information Base .............................. 23
1. このMemoの状態… 3 2. 序論… 4 部分I: 概念とモデル… 7 3. OSI管理フレームワーク… 7 3.1. 建築概要… 7 3.2. 管理はモデル化されます… 8 3.2.1. 組織的なモデル… 8 3.2.2. 機能論的モデル… 8 3.2.3. 情報モデル… 9 3.3. ISOアプリケーション・プロトコル… 9 3.3.1. ACSE… 10 3.3.2. 上昇しました… 10 3.3.3. CMISE… 10 3.3.3.1. 管理協会サービス… 11 3.3.3.2. 管理通知サービス… 12 3.3.3.3. 管理操作サービス… 12 4. CMOTアーキテクチャ… 13 4.1. 管理はモデル化されます… 13 4.1.1. 組織的なモデル… 13 4.1.2. 機能論的モデル… 14 4.1.3. 情報モデル… 14 4.2. アーキテクチャについて議定書の中で述べてください… 14 4.2 .1 軽量のプレゼンテーション層… 15 4.2 .2 輸送サービスの品質… 16 4.3. プロキシ管理… 17 4.4. ディレクトリサービス… 18 5. 管理情報… 18 5.1. 経営情報の構造… 19 5.1.1. ISO SMI… 19 5.1.1.1. 管理オブジェクトと属性… 19 5.1.1.2. 経営情報階層構造… 20 5.1 .1 .2 .1 登録階層構造… 20 5.1.1.2.2. 包含階層… 20 5.1.1.2.3. 継承階層構造… 22 5.1.2. インターネットSMI… 22 5.2. 管理情報ベース… 23
Warrier & Besaw [Page 1] RFC 1095 CMOT April 1989
Warrier&Besaw[1ページ]RFC1095CMOT1989年4月
5.3. An Interpretation of the Internet SMI ........................ 24 5.3.1. Object Class and Attributes ................................ 25 5.3.1.1. Object Class ............................................. 25 5.3.1.2. Attribute Identifier ..................................... 26 5.3.2. Management Information Hierarchies ......................... 26 5.3.2.1. The Registration Hierarchy ............................... 26 5.3.2.2. The Containment Hierarchy ................................ 26 5.3.2.3. The Inheritance Hierarchy ................................ 28 5.4. Scoping, Filtering, and Synchronization ...................... 28 5.4.1. Scoping .................................................... 28 5.4.2. Filtering .................................................. 29 5.4.3. Synchronization ............................................ 29 5.4.4. Linked Replies ............................................. 29 5.5. Accessing Tables ............................................. 29 5.5.1. Accessing Whole Tables ..................................... 30 5.5.2. Accessing Table Entries .................................... 30 Part II: Protocol Agreements ...................................... 32 6. CMOT Protocol Overview ......................................... 32 6.1. The CMOT Protocol Suite ...................................... 32 6.2. Conformance Requirements ..................................... 33 6.3. Abstract Syntax Notation ..................................... 33 7. Common Management Information Service Element .................. 34 7.1. CMIS Services ................................................ 34 7.1.1. CMIS Services Overview ..................................... 34 7.1.2. Functional Units ........................................... 34 7.1.3. Functional Unit Groups ..................................... 36 7.1.4. M-INITIALISE Parameters .................................... 37 7.1.4.1. Functional Units ......................................... 37 7.1.4.2. User Information ......................................... 39 7.1.4.3. Access Control ........................................... 39 7.2. Supporting Services .......................................... 39 7.3. CMIP Agreements .............................................. 39 7.3.1. Invoke Identifier .......................................... 39 7.3.2. Object Class ............................................... 40 7.3.3. Object Instance ............................................ 40 7.3.4. Access Control ............................................. 41 7.3.5. Synchronization ............................................ 41 7.3.6. Scope ...................................................... 41 7.3.7. Filter ..................................................... 41 7.3.8. Attribute Identifier ....................................... 42 7.3.9. Event Type Identifier ...................................... 42 7.3.10. Action Type Identifier .................................... 42 7.3.11. Time Fields ............................................... 43 7.3.12. Response PDUs ............................................. 43 7.3.13. Error PDUs ................................................ 43 8. Association Control Service Element ............................ 43 8.1. ACSE Services ................................................ 44 8.2. Supporting Services .......................................... 44
5.3. インターネットSMIの解釈… 24 5.3.1. オブジェクトのクラスと属性… 25 5.3.1.1. クラスは反対します… 25 5.3.1.2. 識別子を結果と考えてください… 26 5.3.2. 経営情報階層構造… 26 5.3.2.1. 登録階層構造… 26 5.3.2.2. 包含階層… 26 5.3.2.3. 継承階層構造… 28 5.4. 見る、フィルタリング、および同期… 28 5.4.1. 見ます… 28 5.4.2. フィルターにかけます。 29 5.4.3. 同期… 29 5.4.4. 回答をリンクします… 29 5.5. テーブルにアクセスします… 29 5.5.1. 全体のテーブルにアクセスします… 30 5.5.2. テーブル項目にアクセスします… 30 パートII: 協定について議定書の中で述べてください… 32 6. CMOTは概要について議定書の中で述べます… 32 6.1. CMOTはスイートについて議定書の中で述べます… 32 6.2. 順応要件… 33 6.3. 抽象構文記法… 33 7. 共通管理情報サービス要素… 34 7.1. CMISサービス… 34 7.1.1. CMISは概要を修理します… 34 7.1.2. 機能的なユニット… 34 7.1.3. 機能的なユニットは分類されます… 36 7.1.4. パラメタをM初期化してください… 37 7.1.4.1. 機能的なユニット… 37 7.1.4.2. ユーザ情報… 39 7.1.4.3. コントロールにアクセスしてください… 39 7.2. サービスをサポートします… 39 7.3. CMIP協定… 39 7.3.1. 識別子を呼び出してください… 39 7.3.2. クラスは反対します… 40 7.3.3. オブジェクトインスタンス… 40 7.3.4. コントロールにアクセスしてください… 41 7.3.5. 同期… 41 7.3.6. 範囲… 41 7.3.7. フィルターにかけます。 41 7.3.8. 識別子を結果と考えてください… 42 7.3.9. イベントタイプ識別子… 42 7.3.10. 動作タイプ識別子… 42 7.3.11. 時間分野… 43 7.3.12. 応答PDUs… 43 7.3.13. 誤りPDUs… 43 8. アソシエーション制御サービス要素… 43 8.1. ACSEサービス… 44 8.2. サービスをサポートします… 44
Warrier & Besaw [Page 2] RFC 1095 CMOT April 1989
Warrier&Besaw[2ページ]RFC1095CMOT1989年4月
8.3. ACSE Protocol ................................................ 45 8.3.1. Application Context Name ................................... 45 8.3.2. User Information ........................................... 45 8.3.3. Presentation Service Parameters ............................ 46 9. Remote Operations Service Element .............................. 46 9.1. ROSE Services ................................................ 46 9.2. Supporting Services .......................................... 47 9.3. ROSE Protocol ................................................ 47 9.3.1. Operation Class ............................................ 47 9.3.2. Priority ................................................... 48 10. Lightweight Presentation ...................................... 48 10.1. Lightweight Presentation Services ........................... 48 10.2. Supporting Services ......................................... 48 10.3. Lightweight Presentation Protocol ........................... 49 11. Acknowledgements .............................................. 49 12. References .................................................... 49 Appendix A - The CMOT Group ....................................... 52 Appendix B - Management Information Summary ....................... 53 Appendix C - Sample Protocol Exchanges ............................ 60
8.3. ACSEは議定書を作ります… 45 8.3.1. アプリケーション文脈名… 45 8.3.2. ユーザ情報… 45 8.3.3. プレゼンテーション・サービスパラメタ… 46 9. リモート操作は要素を調整します… 46 9.1. バラサービス… 46 9.2. サービスをサポートします… 47 9.3. バラプロトコル… 47 9.3.1. 操作のクラス… 47 9.3.2. 優先権… 48 10. 軽量のプレゼンテーション… 48 10.1. 軽量のプレゼンテーション・サービス… 48 10.2. サービスをサポートします… 48 10.3. 軽量のプレゼンテーションプロトコル… 49 11. 承認… 49 12. 参照… 49 付録A--CMOTは分類します… 52 付録B--経営情報概要… 53 付録C--プロトコル交換を抽出してください… 60
1. Status of this Memo
1. このMemoの状態
This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP-based internets, and in particular the Internet.
このメモはTCP/IP環境で国際標準化機構(ISO)の一般的なManagement情報Services/共通管理情報プロトコル(CMIS/CMIP)を使用するネットワークマネージメントアーキテクチャを定義します。 このアーキテクチャはマネージャとリモートネットワーク要素の間でコントロールと監視情報を交換できる手段を提供します。 特に、このメモはインターネット標準管理情報ベースで定義された経営情報を運ぶ目的のためのインターネットトランスポート・プロトコルの上でCMIS/CMIPの国際規格案(DIS)バージョンを実装するための手段を定義します。 CMIS/CMIPは国際規格になることに向かって移行しますが、DIS CMIS/CMIPはTCP/IPネットワークで展開に適しています。 経営情報と管理情報ベースの初期構造について説明する関連ISO規格と仲間RFCsと共にこれらのドキュメントはTCP/IPベースのインターネット、および特にインターネットを管理する包括的なアーキテクチャとシステムの基礎を提供します。
The Internet Activities Board (IAB) has designated two different network management protocols with the same status of "Draft Standard" and "Recommended".
Activities Board(IAB)には「草稿規格」の同じ状態がある2つの異なったネットワーク管理プロトコルに指定されて、「推薦されること」があるインターネット。
The two protocols are the Common Management Information Services and Protocol over TCP/IP (CMOT) (this memo) and the Simple Network Management Protocol (SNMP) [4].
2つのプロトコルが、TCP/IP(CMOT)(このメモ)の上のCommon Management情報ServicesとプロトコルとSimple Network Managementプロトコル(SNMP)[4]です。
Warrier & Besaw [Page 3] RFC 1095 CMOT April 1989
Warrier&Besaw[3ページ]RFC1095CMOT1989年4月
The IAB intends each of these two protocols to receive the attention of implementers and experimenters. The IAB seeks reports of experience with these two protocols from system builders and users.
それぞれのこれらの2つのプロトコルがIABがimplementersと実験者の配慮を受けるつもりです。 IABはシステムビルダーとユーザからこれらの2つのプロトコルの経験のレポートを求めます。
By this action, the IAB recommends that all IP and TCP implementations be network manageable (e.g., implement the Internet MIB [3], and that implementations that are network manageable are expected to adopt and implement at least one of these two Internet Draft Standards.
この動作で、IABは、すべてのIPとTCP実装がネットワーク処理しやすいのを推薦します。(例えば、MIB[3]、およびそのネットワーク処理しやすい実装が採用して、実装すると予想されるインターネットに、少なくともこれらの2インターネットDraft Standardsの1つを実装してください。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
2. Introduction
2. 序論
As reported in RFC 1052, "IAB Recommendations for the Development of Internet Network Management Standards" [1], the Internet Activities Board (IAB) has directed the Internet Engineering Task Force (IETF) to coordinate the work of three working groups in the area of network management. First, the MIB working group was charged with the specification and definition of elements to be included in the Management Information Base (MIB). Second, the SNMP working group was charged with defining the modifications to the Simple Network Management Protocol (SNMP) necessary to accommodate the short-term needs of the network vendor and operations communities. Third, the Netman working group was directed to meet the longer-term needs of the Internet community by developing a network management system based on ISO CMIS/CMIP. Both the Netman working group and the SNMP working group were directed to align their work with the output of the MIB working group in order to ensure compatibility of management information between the short-term and long-term approaches to the management of TCP/IP-based internets. This will enable a smooth transition from the short-term protocol (SNMP) to the long-term protocol (CMIP).
RFC1052、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」[1]で報告されるように、インターネットActivities Board(IAB)は、ネットワークマネージメントの領域での3つのワーキンググループの仕事を調整するようインターネット・エンジニアリング・タスク・フォース(IETF)に指示しました。 まず最初に、要素の仕様と定義でMIBワーキンググループを告発して、Management Information基地(MIB)に含まれていました。 2番目に、ネットワークベンダと操作共同体の短期的な必要性を収容するのに必要なSimple Network Managementプロトコル(SNMP)への変更を定義することでSNMPワーキンググループを告発しました。 3番目に、NetmanワーキンググループがISO CMIS/CMIPに基づくネットワーク管理システムを開発することによってインターネットコミュニティの、より長い期間需要を満たすよう指示されました。 NetmanワーキンググループとSNMPワーキンググループの両方がTCP/IPベースのインターネットの管理への短期的で長期のアプローチの間の経営情報の互換性を確実にするためにMIBワーキンググループの出力に彼らの仕事を一直線にするよう指示されました。 これは短期的なプロトコル(SNMP)から長期のプロトコル(CMIP)までのスムーズな移行を可能にするでしょう。
The MIB working group has produced two memos. RFC 1065 [2] defines the Structure of Management Information (SMI) that is necessary for naming and defining managed objects in the MIB. RFC 1066 [3] defines the list of managed objects contained in the initial TCP/IP MIB. The SNMP working group has produced a memo [4] giving the protocol specification for SNMP and providing the SNMP protocol-specific interpretation of the Internet-standard MIB defined in RFC 1066.
MIBワーキンググループは2つのメモを製作しました。 RFC1065[2]はMIBで管理オブジェクトを命名して、定義するのに必要なManagement情報(SMI)のStructureを定義します。 RFC1066[3]は初期のTCP/IP MIBに含まれた管理オブジェクトのリストを定義します。 SNMPワーキンググループは、SNMPのためのプロトコル仕様を与えて、RFC1066で定義されたインターネット標準MIBのSNMPのプロトコル特有の解釈を提供しながら、メモ[4]を製作しました。
This memo is the output of the Netman working group. As directed by the IAB in RFC 1052, it addresses the need for a long-term network management system based on ISO CMIS/CMIP. The network management approach of using ISO protocols in a TCP/IP environment to manage TCP/IP networks can be described as "CMIP Over TCP/IP" (CMOT). This memo specifies the CMOT architecture and the protocol agreements
このメモはNetmanワーキンググループの出力です。 RFC1052でIABによって指示されるように、それはISO CMIS/CMIPに基づく長期のネットワーク管理システムの必要性を扱います。 TCP/IPネットワークを経営するのにTCP/IP環境でISOプロトコルを使用するネットワークマネージメントアプローチを「TCP/IPの上のCMIP」(CMOT)として記述できます。 このメモはCMOTアーキテクチャとプロトコル協定を指定します。
Warrier & Besaw [Page 4] RFC 1095 CMOT April 1989
Warrier&Besaw[4ページ]RFC1095CMOT1989年4月
necessary to implement CMIP and accompanying ISO protocols over the TCP and UDP transport protocols. In addition, this memo provides an interpretation of RFC 1066 that makes it possible to use CMIP to convey management information defined in the Internet-standard MIB.
TCPとUDPトランスポート・プロトコルの上でCMIPと付随のISOがプロトコルであると実装するために、必要です。 さらに、このメモはインターネット標準MIBで定義された経営情報を伝えるのにCMIPを使用するのを可能にするRFC1066の解釈を提供します。
There is widespread vendor support for the CMOT approach to network management. This is amply shown by the Netman demonstration of prototype CMOT implementations at the Interop '88 TCP/IP Interoperability Conference. The demonstration also showed the feasibility and power of the CMIS/CMIP framework for multivendor network management. Now that CMIS/CMIP has been voted a Draft International Standard (DIS), many vendors feel that the ISO standard has become a stable basis for product development. The clear need to standardize this development has led to the present profile of CMIP. It is expected that this profile will not change while the ISO standard moves from DIS status to International Standard (IS) status. If, however, the standard does change unexpectedly, the Netman working group will review such changes for appropriate action.
ネットワークマネージメントへのCMOTアプローチの広範囲のベンダーサポートがあります。 これはInterop88年のTCP/IP InteroperabilityコンファレンスにおけるプロトタイプCMOT実装のNetmanデモンストレーションで十分に示されます。 また、デモンストレーションは「マルチ-ベンダー」ネットワークマネージメントのためにCMIS/CMIPフレームワークの実行可能性とパワーを示しました。 CMIS/CMIPが国際規格案(DIS)であることに投票されたので、多くのベンダーが、ISO規格が商品開発の安定した基礎になったのを感じます。 この開発を標準化する明確な必要性はCMIPの現在のプロフィールに通じました。 ISO規格がDIS状態から国際規格(ある)状態まで移行している間このプロフィールが変化しないと予想されます。 しかしながら、規格が不意に変化すると、Netmanワーキンググループは適切な行動のためにそのような変化を見直すでしょう。
Another rationale for the CMOT approach is that it will facilitate the early use of ISO network management standards in large operational networks. This will make it possible for the Internet community to make valuable recommendations to ISO in the language of OSI management based on actual experience with the use and implementation of these standards. There is continuing network management standards development work in ISO where such contributions would be valuable.
CMOTアプローチのための別の原理は大きい操作上のネットワークにおけるISOネットワークマネージメント規格の早めの使用を容易にするということです。 これで、インターネットコミュニティがOSIの言葉を借りて言えばISOへの貴重な推薦状をこれらの規格の使用と実装の実地経験に基づく管理にするのが可能になるでしょう。 継続するネットワークマネージメント規格開発事業がそのような貢献が貴重であるISOにあります。
The CMOT architecture is based on the Open Systems Interconnection (OSI) management framework and models developed by ISO. This memo contains a set of protocol agreements for implementing a network management system based on this architecture. The protocol agreement sections of this memo must be read in conjunction with ISO and Internet documents defining specific protocol standards. Documents defining the following ISO standards are required for the implementor: Abstract Syntax Notation One (ASN.1) [5, 6], Association Control (ACSE) [7, 8], Remote Operations (ROSE) [9, 10], Common Management Information Services (CMIS) [11], and Common Management Information Protocol (CMIP) [12]. RFC 1085 [13] is required for the specification of a lightweight presentation layer protocol used in this profile. In addition, RFC 1065 [2] and RFC 1066 [3] are required for a definition of the initial SMI and MIB to be used with the CMOT management system.
CMOTアーキテクチャはISOによって開発されたオープン・システム・インターコネクション(OSI)管理フレームワークとモデルに基づいています。 このメモはこのアーキテクチャに基づくネットワーク管理システムを実装するためのプロトコル協定一式を含んでいます。 特定のプロトコル標準を定義するISOとインターネットドキュメントに関連してこのメモのプロトコル協定部を読まなければなりません。 以下のISO規格を定義するドキュメントが作成者に必要です: 抽象構文記法1(ASN.1)[5、6]、アソシエーション制御(ACSE)[7、8]、リモート操作(バラ)[9、10]、共通管理情報サービス(CMIS)[11]、および一般的な経営情報は(CMIP)[12]について議定書の中で述べます。 RFC1085[13]がこのプロフィールで使用される軽量のプレゼンテーション層プロトコルの仕様に必要です。 さらに、RFC1065[2]とRFC1066[3]が、初期のSMIとMIBの定義がCMOTマネージメントシステムと共に使用されるのに必要です。
This memo is divided into two main parts. The first part presents concepts and models; the second part contains the protocol agreements necessary for implementation of the CMOT network management system. The first part of the memo is divided into three sections: section 3
このメモは2つの主部に分割されます。 最初の部分は概念とモデルを提示します。 第二部はCMOTネットワーク管理システムの実装に必要なプロトコル協定を含んでいます。 メモの最初の部分は3つのセクションに分割されます: セクション3
Warrier & Besaw [Page 5] RFC 1095 CMOT April 1989
Warrier&Besaw[5ページ]RFC1095CMOT1989年4月
contains tutorial information on the OSI management framework; section 4 defines the basic CMOT approach; and section 5 discusses the area of management information and specifies how the abstract management information defined in the Internet-standard SMI and MIB map into CMIP. The second part of this memo is divided into sections for each of the protocols for which implementors' agreements are needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol. The protocol profile defined in this part draws on the technical work of the OSI Network Management Forum [14] and the Network Management Special Interest Group (NMSIG) of the National Institute of Standards and Technology (NIST) (formerly the National Bureau of Standards). Wherever possible, an attempt has been made to remain consistent with the protocol agreements reached by these groups.
OSI管理フレームワークの家庭教師の情報を含んでいます。 セクション4は基本的なCMOTアプローチを定義します。 そして、セクション5は、経営情報の領域について論じて、抽象的な経営情報がインターネット標準のSMIとMIBで地図をどうCMIPと定義したかを指定します。 このメモの第二部は実装者間協定が必要であるそれぞれのプロトコルのためにセクションに分割されます: CMISE、ACSE、ローズ、および軽量のプレゼンテーションは議定書を作ります。 この部分で定義されたプロトコルプロフィールは米国商務省標準技術局(NIST)(以前規格基準局)のOSI Network Management Forum[14]とNetwork Management特別利益団体Group(NMSIG)の技術的な仕事を利用します。 どこでも、可能であるところでは、これらのグループによって達せられているプロトコル合意と一致していたままで残っているのを試みをしました。
Warrier & Besaw [Page 6] RFC 1095 CMOT April 1989
Warrier&Besaw[6ページ]RFC1095CMOT1989年4月
Part I: Concepts and Models
部分I: 概念とモデル
3. The OSI Management Framework
3. OSI管理フレームワーク
The OSI management framework [15] presents the basic concepts and models required for developing network management standards. OSI management provides the ability to monitor and control network resources, which are represented as "managed objects." The following elements are essential for the description of a network management architecture and the standardization of a network management system: a model or set of models for understanding management; a common structure of management information for registering, identifying, and defining managed objects; detailed specifications of the managed objects; and a set of services and related protocols for performing remote management operations.
OSI管理フレームワーク[15]は基本概念を提示します、そして、モデルが展開しているネットワークマネージメント規格に必要です。 OSI経営者側はモニターする能力と制御ネットワーク資源を提供します。(ネットワーク資源は「管理オブジェクト」として表されます)。 ネットワークマネージメントアーキテクチャの記述とネットワーク管理システムの規格化に、以下の要素は不可欠です: 管理を理解するためのモデルのモデルかセット。 管理オブジェクトを登録して、特定して、定義するための経営情報の一般的な構造。 管理オブジェクトの仕様詳細。 そして、リモート管理操作を実行するためのサービスと関連するプロトコルのセット。
3.1. Architectural Overview
3.1. 建築概要
The basic concepts underlying OSI network management are quite simple [16]. There reside application processes called "managers" on managing systems (or management stations). There reside application processes called "agents" on managed systems (or network elements being managed). Network management occurs when managers and agents conspire (via protocols and a shared conceptual schema) to exchange monitoring and control information useful to the management of a network and its components. The terms "manager" and "agent" are also used in a loose and popular sense to refer to the managing and managed system, respectively.
OSIネットワークマネージメントの基礎となる基本概念はかなり簡単な[16]です。 管理システム(または、管理局)の上の「マネージャ」と呼ばれるアプリケーション・プロセスはあります。 管理されたシステム(または、管理されるネットワーク要素)の上の「エージェント」と呼ばれるアプリケーション・プロセスはあります。 マネージャとエージェントが、ネットワークとそのコンポーネントの経営の役に立つモニターと制御情報を交換するのを共謀するとき(プロトコルと共有された概念スキーマで)、ネットワークマネージメントは起こります。 また、「マネージャ」と「エージェント」という用語はそれぞれ管理と管理されたシステムを示すゆるくてポピュラーな意味で使用されます。
The shared conceptual schema mentioned above is a priori knowledge about "managed objects" concerning which information is exchanged. Managed objects are system and networking resources (e.g., a modem, a protocol entity, an IP routing table, a TCP connection) that are subject to management. Management activities are effected through the manipulation of managed objects in the managed systems. Using the management services and protocol, the manager can direct the agent to perform an operation on a managed object for which it is responsible. Such operations might be to return certain values associated with a managed object (read a variable), to change certain values associated with a managed object (set a variable), or perform an action (such as self-test) on the managed object. In addition, the agent may also forward notifications generated asynchronously by managed objects to the manager (events or traps).
前記のように共有された概念スキーマは情報が交換される「管理オブジェクト」に関する先験的な知識です。 管理オブジェクトは、管理を受けることがあるシステムとネットワークリソース(例えば、モデム、プロトコル実体、IP経路指定テーブル、TCP接続)です。 管理されたシステムにおける、管理オブジェクトの操作で管理活動は作用します。経営指導とプロトコルを使用して、マネージャは、それが責任がある管理オブジェクトに操作を実行するようエージェントに指示できます。 そのような操作は管理オブジェクト(変数を設定する)に関連しているある値を変えるか、または管理オブジェクトへの動作(自己診断などの)を実行するために管理オブジェクト(変数を読む)に関連しているある値を返すことであるかもしれません。 また、さらに、エージェントは管理オブジェクトによってマネージャ(イベントか罠)に非同期に生成された通知を転送するかもしれません。
The terms "manager" and "agent" are used to denote the asymmetric relationship between management application processes in which the manager plays the superior role and the agent plays the subordinate.
「マネージャ」と「エージェント」という用語は、マネージャが優れた役割を果たして、エージェントが部下を演じる管理アプリケーション・プロセスの間の非対称の関係を指示するのに使用されます。
Warrier & Besaw [Page 7] RFC 1095 CMOT April 1989
Warrier&Besaw[7ページ]RFC1095CMOT1989年4月
However, the specification of the management protocol (CMIP) defines a peer protocol relationship that makes no assumptions concerning which end opens or closes a connection, or the direction of management data transfer. The protocol mechanisms provided are fully symmetric between the manager and the agent; CMIS operations can originate at either the manager or agent, as far as the protocol is concerned. This allows the possibility of symmetric as well as asymmetric relationships between management processes. Most devices will contain management applications that can only assume the agent role. Applications on managing systems, however, may well be able to play both roles at the same time. This makes possible "manager to manager" communication and the ability of one manager to manage another.
しかしながら、管理プロトコル(CMIP)の仕様はいずれの終わりが接続を開くか、または終える仮定も、または管理データ転送の方向もしない同輩プロトコル関係を定義します。 提供されたプロトコルメカニズムはマネージャとエージェントの間で完全に左右対称です。 プロトコルに関する限り、CMIS操作はどちらかでマネージャかエージェントを溯源できます。 これは管理過程の間の左右対称の、そして、非対称の関係の可能性を許容します。 ほとんどのデバイスがエージェントの役割を引き受けることができるだけである管理アプリケーションを含むでしょう。 しかしながら、システムを管理するときのアプリケーションは同時に、たぶん両方の役割を果たすことができるでしょう。 これは「マネージャのマネージャ」可能なコミュニケーションと1人のマネージャが別のものを管理する能力になります。
3.2. Management Models
3.2. マネジメント・モデル
Network management may be modeled in different ways. Three models are typically used to describe OSI management [17, 18]. An organizational model describes ways in which management can be administratively distributed. The functional model describes the management functions and their relationships. The information model provides guidelines for describing managed objects and their associated management information.
ネットワークマネージメントは異なった方法でモデル化されるかもしれません。 3つのモデルが、OSI管理[17、18]について説明するのに通常使用されます。 組織的なモデルは行政上管理を広げることができる方法を述べます。 機能論的モデルは管理機能とそれらの関係について説明します。 情報モデルは管理オブジェクトについて説明するためのガイドラインとそれらの関連経営情報を提供します。
3.2.1. The Organizational Model
3.2.1. 組織的なモデル
The organizational model introduces the concept of a management "domain." A domain is an administrative partition of a network or internet for the purpose of network management. Domains may be useful for reasons of scale, security, or administrative autonomy. Each domain may have one or more managers monitoring and controlling agents in that domain. In addition, both managers and agents may belong to more than one management domain. Domains allow the construction of both strict hierarchical and fully cooperative and distributed network management systems.
組織的なモデルは管理「ドメイン」の概念を紹介します。 ドメインはネットワークマネージメントの目的のためのネットワークかインターネットの管理パーティションです。 ドメインはスケール、セキュリティ、または管理自治の理由の役に立つかもしれません。 各ドメインは、1人以上のマネージャがそのドメインでエージェントをモニターして、監督するのをさせるかもしれません。 さらに、マネージャとエージェントの両方が1つ以上の管理ドメインに属すかもしれません。 ドメインは両方の厳しい階層的で完全に協力的で分配されたネットワーク管理システムの工事を許します。
3.2.2. The Functional Model
3.2.2. 機能論的モデル
The OSI Management Framework [15] defines five facilities or functional areas to meet specific management needs. This has proved to be a helpful way of partitioning the network management problem from an application point of view. These facilities have come to be known as the Specific Management Functional Areas (SMFAs): fault management, configuration management, performance management, accounting management, and security management. Fault management provides the ability to detect, isolate, and correct network problems. Configuration management enables network managers to change the configuration of remote network elements. Performance
OSI Management Framework[15]は、特定の管理需要を満たすために5つの施設か機能的な領域を定義します。 これはアプリケーション観点からネットワーク管理問題を仕切る役立っている方法であると判明しました。 これらの施設はSpecific Management Functional Areas(SMFAs)として知られるようになりました: 障害管理、構成管理、パフォーマンス管理、会計管理、およびセキュリティ管理。 障害管理はネットワーク問題を検出して、隔離して、修正する能力を前提とします。構成管理は、ネットワークマネージャがリモートネットワーク要素の構成を変えるのを可能にします。 パフォーマンス
Warrier & Besaw [Page 8] RFC 1095 CMOT April 1989
Warrier&Besaw[8ページ]RFC1095CMOT1989年4月
management provides the facilities to monitor and evaluate the performance of the network. Accounting management makes it possible to charge users for network resources used and to limit the use of those resources. Finally, security management is concerned with managing access control, authentication, encryption, key management, and so on.
経営者側は、ネットワークの性能をモニターして、評価するために施設を提供します。 会計管理は使用されるネットワーク資源のためにユーザを告発して、それらのリソースの使用を制限するのを可能にします。 最終的に、セキュリティ管理はアクセスコントロール、認証、暗号化、かぎ管理などを経営するのに関係があります。
3.2.3. The Information Model
3.2.3. 情報モデル
The OSI Management Framework considers all information relevant to network management to reside in a Management Information Base (MIB), which is a "conceptual repository of management information." Information within a system that can be referenced by the management protocol (CMIP) is considered to be part of the MIB. Conventions for describing and uniquely identifying the MIB information allow specific MIB information to be referenced and operated on by the management protocol. These conventions are called the Structure of Management Information (SMI). The information model is described more fully in section 5.
OSI Management Frameworkは、ネットワークマネージメントに関連しているすべての情報がManagement Information基地(MIB)の中にあると考えます。基地は「経営情報の概念的な倉庫」です。 管理プロトコル(CMIP)で参照をつけることができるシステムの中の情報はMIBの一部であると考えられます。 MIB情報を説明して、唯一特定するためのコンベンションは、特定のMIB情報が参照をつけられて、管理プロトコルによって作動させられるのを許容します。 これらのコンベンションはManagement情報(SMI)のStructureと呼ばれます。 情報モデルはセクション5で、より完全に説明されます。
3.3. ISO Application Protocols
3.3. ISOアプリケーション・プロトコル
The following ISO application services and protocols are necessary for doing network management using the OSI framework: ACSE, ROSE, and CMIS/CMIP. All three of these protocols are defined using ASN.1 [5]. The ASN.1 modules defining each of these protocols are found in the relevant standards documents. The encoding rules for ASN.1 [6] provide a machine-independent network representation for data.
以下のISOアプリケーション・サービスとプロトコルがOSIフレームワークを使用することでネットワークマネージメントをするのに必要です: ACSE、ローズ、およびCMIS/CMIP。 これらのすべての3つのプロトコルが、ASN.1[5]を使用することで定義されます。 それぞれのこれらのプロトコルを定義するASN.1モジュールは関連規格文書で見つけられます。 ASN.1[6]のための符号化規則はデータのマシンから独立しているネットワーク表現を提供します。
A brief overview of the terminology associated with the OSI application layer structure is presented here. A complete treatment of the subject can be found in the OSI Application Layer Structure document [22].
OSIアプリケーション層状構造に関連している用語の簡潔な概要はここに提示されます。 OSI Application Layer Structureドキュメント[22]で対象の完全な処理を見つけることができます。
In the OSI environment, communication between "application processes" is modeled by communication between application entities. An "application entity" represents the communication functions of an application process. There may be multiple sets of OSI communication functions in an application process, so a single application process may be represented by multiple application entities. However, each application entity represents a single application process. An application entity contains a set of communication capabilities called "application service elements." An application service element is a coherent set of integrated functions. These application service elements may be used independently or in combination. Examples of application service elements are X.400, FTAM, ACSE, ROSE, and CMISE.
OSI環境で、「アプリケーション・プロセス」のコミュニケーションはアプリケーション実体のコミュニケーションによってモデル化されます。 「アプリケーション実体」はアプリケーション・プロセスの通信機能を表します。 複数のセットのOSI通信機能がアプリケーション・プロセスにあるかもしれないので、ただ一つのアプリケーション・プロセスは複数のアプリケーション実体によって表されるかもしれません。 しかしながら、それぞれのアプリケーション実体はただ一つのアプリケーション・プロセスを表します。 アプリケーション実体は「応用サービス要素」と呼ばれる1セットのコミュニケーション能力を含んでいます。 応用サービス要素は一貫性を持っている統合機能です。 これらの応用サービス要素は独自か組み合わせに使用されるかもしれません。 応用サービス要素に関する例は、X.400と、FTAMと、ACSEと、ローズと、CMISEです。
When communication is required between two application entities, one
コミュニケーションが2つのアプリケーション実体、1の間で必要であるときに
Warrier & Besaw [Page 9] RFC 1095 CMOT April 1989
Warrier&Besaw[9ページ]RFC1095CMOT1989年4月
or more "application associations" are established between them. Such an association can be viewed as a connection at the level of the application layer. An "application context" defines the set of application service elements which may be invoked by the user of an application association. The application context may prescribe one or more application service elements.
または、より多くの「応用アソシエーション」がそれらの間に設立されます。 接続として応用層のレベルでそのような協会を見なすことができます。 「アプリケーション文脈」は応用アソシエーションのユーザによって呼び出されるかもしれない応用サービス要素のセットを定義します。 アプリケーション文脈は1個以上の応用サービス要素を定めるかもしれません。
Generally, an "application layer protocol" is realized by the use of the functionality of a number of application service elements. This functionality is provided by the specification of a set of application protocol data units (APDUs) and the procedures governing their use. In general, the operation of an application layer protocol may require the combination of APDUs from different application service elements. The application entity makes direct use of presentation context identifiers for the specification and identification of APDUs.
一般に、「応用層プロトコル」は多くの応用サービス要素の機能性の使用で実感されます。 1セットのアプリケーション・プロトコルデータ単位(APDUs)と彼らの使用を治める手順の仕様でこの機能性を提供します。 一般に、応用層プロトコルの操作は異なった応用サービス要素からAPDUsの組み合わせを必要とするかもしれません。 アプリケーション実体はAPDUsの仕様と識別のためのプレゼンテーション文脈識別子をダイレクトに利用します。
3.3.1. ACSE
3.3.1. ACSE
The Association Control Service Element (ACSE) is used to establish and release associations between application entities. Before any management operations can be performed using CMIP, it is necessary for the two application entities involved to form an association. Either the manager or the agent can initiate association establishment. ACSE allows the manager and agent to exchange application entity titles for the purpose of identification and application context names to establish an application context. As stated above, an application context defines what service elements (for instance, ROSE and CMISE) may be used over the association. After the association is established, ACSE is not used again until the association is released by the manager or agent.
アソシエーション制御サービス要素(ACSE)は、アプリケーション実体の間の協会を設立して、リリースするのに使用されます。 CMIPを使用することでどんな管理操作も実行できる前に、結社を作るのが実体がかかわった2アプリケーションに必要です。 マネージャかエージェントのどちらかが協会設立を開始できます。 識別とアプリケーション文脈名の目的がアプリケーション文脈を証明するように、ACSEはマネージャとエージェントにアプリケーション実体タイトルを交換させます。 上では、アプリケーション文脈が、どんなサービス要素(例えば、ローズとCMISE)が協会の上で使用されるかもしれないかを定義すると述べるので。 協会が設立された後に、協会がマネージャかエージェントによってリリースされるまで、ACSEは再び使用されません。
3.3.2. ROSE
3.3.2. 上昇しました。
The Remote Operation Service Element (ROSE) is the ISO equivalent of remote procedure call. ROSE allows the invocation of an operation to be performed on a remote system. The Remote Operation protocol contains an invoke identifier for correlating requests and responses, an operation code, and an argument field for parameters specific to the operation. ROSE can only be invoked once an application association has been established. CMIP uses the transaction-oriented services provided by ROSE for all its requests and responses. CMIP also uses the error response facilities provided by ROSE.
Remote Operation Service Element(ローズ)は遠隔手続き呼び出しのISO同等物です。 ローズはリモートシステムに操作の実施を実行させます。 Remote Operationプロトコルが含んでいる、操作に特定のパラメタのために要求、応答、命令コード、および議論分野を関連させるように識別子を呼び出してください。 応用アソシエーションがいったん設立されると、ローズを呼び出すことができるだけです。 CMIPはローズによってそのすべての要求と応答に提供されたトランザクション指向のサービスを利用します。 また、CMIPはローズによって提供された誤り応答施設を使用します。
3.3.3. CMISE
3.3.3. CMISE
The Common Management Information Service Element (CMISE) is the service element that provides the basic management services. The
Common Management情報Service Element(CMISE)は基本的な経営指導を提供するサービス要素です。 The
Warrier & Besaw [Page 10] RFC 1095 CMOT April 1989
Warrier&Besaw[10ページ]RFC1095CMOT1989年4月
CMISE is a user of both ROSE and ACSE. The CMISE provides both confirmed and unconfirmed services for reporting events and retrieving and manipulating management data. These services are used by manager and agent application entities to exchange management information. Table 1 provides a list of the CMISE services. In addition, the CMISE also provides the ability to issue a series of (multiple) linked replies in response to a single request.
CMISEはローズとACSEの両方のユーザです。 CMISEは確認されたものと管理データをイベントを報告して、検索して、操るための同様に未確認のサービスを提供します。 これらのサービスはマネージャとエージェントアプリケーション実体によって利用されて、経営情報を交換します。 テーブル1はCMISEサービスのリストを提供します。 また、さらに、CMISEはただ一つの要求に対応して一連の(複数)の繋がっている回答を発行する能力を提供します。
+-----------------+-------------------------+
| Service | Type |
+-----------------+-------------------------+
| M-INITIALISE | confirmed |
| M-TERMINATE | confirmed |
| M-ABORT | non-confirmed |
| M-EVENT-REPORT | confirmed/non-confirmed |
| M-GET | confirmed |
| M-SET | confirmed/non-confirmed |
| M-ACTION | confirmed/non-confirmed |
| M-CREATE | confirmed |
| M-DELETE | confirmed |
+-----------------+-------------------------+
+-----------------+-------------------------+ | サービス| タイプ| +-----------------+-------------------------+ | M初期化します。| 確認されます。| | M終わってください。| 確認されます。| | Mアボート| 非確認されています。| | イベントが報告するM| 確認されるか非確認されています。| | M得てください。| 確認されます。| | Mに設定されています。| 確認されるか非確認されています。| | M動作| 確認されるか非確認されています。| | M作成します。| 確認されます。| | M削除します。| 確認されます。| +-----------------+-------------------------+
Table 1. CMISE Service Summary
1を見送ってください。 CMISEサービス概要
CMIS services can be divided into two main classes: management association services and information transfer services. Furthermore, there are two types of information transfer services: management notification services and management operation services. In addition to the other CMIS services, the CMISE provides facilities that enable multiple responses to confirmed operations to be linked to the operation by the use of a linked identification parameter.
CMISサービスを2つの主なクラスに分割できます: 管理協会サービスと情報はサービスを移します。 その上、2つのタイプの情報転送サービスがあります: 管理通知サービスと管理操作サービス。 他のCMISサービスに加えて、CMISEは動作確認済みへの複数の応答が繋がっている識別パラメタの使用で操作にリンクされるのを可能にする施設を提供します。
3.3.3.1. Management Association Services
3.3.3.1. 管理協会サービス
CMIS provides services for the establishment and release of application associations. These services control the establishment and normal and abnormal release of a management association. These services are simply pass-throughs to ACSE.
CMISは応用アソシエーションの設立とリリースのためのサービスを提供します。 これらのサービスは管理協会の設立と通常の、そして、異常なリリースを制御します。 これらのサービスは単にACSEへのパス-throughsです。
The M-INITIALISE service is invoked by a CMISE-service-user to establish an association with a remote CMISE-service-user for the purpose of exchanging management information. A reply is expected. (A CMISE-service-user is that part of an application process that makes use of the CMISE.)
M-INITIALISEサービスは、経営情報を交換する目的のためにリモートCMISE-サービス利用者との仲間を証明するためにCMISE-サービス利用者によって呼び出されます。 回答は予想されます。 (CMISE-サービス利用者はCMISEを利用するアプリケーション・プロセスのその部分です。)
The M-TERMINATE service is invoked by a CMISE-service-user to release
M-TERMINATEサービスは釈放するCMISE-サービス利用者によって呼び出されます。
Warrier & Besaw [Page 11] RFC 1095 CMOT April 1989
Warrier&Besaw[11ページ]RFC1095CMOT1989年4月
an association with a remote CMISE-service-user in an orderly manner. A reply is expected.
規則的な方法によるリモートCMISE-サービス利用者との仲間。 回答は予想されます。
The M-ABORT service is invoked by a CMISE-service-user or a CMISE- service-provider to release an association with a remote CMISE- service-user in an abrupt manner.
M-ABORTサービスは、ぶっきらぼうにリモートCMISEサービス利用者との仲間を釈放するためにCMISE-サービス利用者かCMISEサービスプロバイダーによって呼び出されます。
3.3.3.2. Management Notification Services
3.3.3.2. 管理通知サービス
The definition of notification and the consequent behavior of the communicating entities is dependent upon the specification of the managed object which generated the notification and is outside the scope of CMIS. CMIS provides the following service to convey management information applicable to notifications.
通知の定義と交信実体の結果の振舞いは、通知を生成した管理オブジェクトの仕様に依存していて、CMISの範囲の外にあります。 CMISは、通知に適切な経営情報を伝えるために以下のサービスを提供します。
The M-EVENT-REPORT service is invoked by a CMISE-service-user to report an event about a managed object to a remote CMISE-service- user. The service may be requested in a confirmed or a non-confirmed mode. In the confirmed mode, a reply is expected.
M-EVENT-REPORTサービスは、管理オブジェクトに関してリモートCMISE-サービスユーザにイベントを報告するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたaか非確認されたモードで要求されているかもしれません。 確認されたモードで、回答は予想されます。
3.3.3.3. Management Operation Services
3.3.3.3. 管理操作サービス
The definition of the operation and the consequent behavior of the communicating entities is dependent upon the specification of the managed object at which the operation is directed and is outside the scope of CMIS. However, certain operations are used frequently within the scope of management and CMIS provides the following definitions of the common services that may be used to convey management information applicable to the operations.
操作の定義と交信実体の結果の振舞いは、操作が指示されている管理オブジェクトの仕様に依存していて、CMISの範囲の外にあります。 しかしながら、ある操作は管理の範囲の中で頻繁に使用されます、そして、CMISは操作に適切な経営情報を伝えるのに使用されるかもしれない共益サービスの以下の定義を提供します。
The M-GET service is invoked by a CMISE-service-user to request the retrieval of management information from a remote CMISE-service-user. The service may only be requested in a confirmed mode. A reply is expected.
M-GETサービスは、リモートCMISE-サービス利用者から経営情報の検索を要求するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたモードで要求されているだけであるかもしれません。 回答は予想されます。
The M-SET service is invoked by a CMISE-service-user to request the modification of management information by a remote CMISE-service- user. The service may be requested in a confirmed or a non-confirmed mode. In the confirmed mode, a reply is expected.
M-SETサービスは、リモートCMISE-サービスユーザによる経営情報の変更を要求するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたaか非確認されたモードで要求されているかもしれません。 確認されたモードで、回答は予想されます。
The M-ACTION service is invoked by a CMISE-service-user to request a
remote CMISE-service-user to perform an action. The service may be
requested in a confirmed or a non-confirmed mode. In the confirmed
mode, a reply is expected.
M-ACTIONサービスは、動作を実行するようリモートCMISE-サービス利用者に要求するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたaか非確認されたモードで要求されているかもしれません。 確認されたモードで、回答は予想されます。
The M-CREATE service is invoked by a CMISE-service-user to request a remote CMISE-service-user to create another instance of a managed object. The service may only be requested in a confirmed mode. A
M-CREATEサービスは、管理オブジェクトの別のインスタンスを作成するようリモートCMISE-サービス利用者に要求するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたモードで要求されているだけであるかもしれません。 A
Warrier & Besaw [Page 12] RFC 1095 CMOT April 1989
Warrier&Besaw[12ページ]RFC1095CMOT1989年4月
reply is expected.
回答は予想されます。
The M-DELETE service is invoked by a CMISE-service-user to request a remote CMISE-service-user to delete an instance of a managed object. The service may only be requested in a confirmed mode. A reply is expected.
M-DELETEサービスは、管理オブジェクトのインスタンスを削除するようリモートCMISE-サービス利用者に要求するためにCMISE-サービス利用者によって呼び出されます。 サービスは確認されたモードで要求されているだけであるかもしれません。 回答は予想されます。
4. The CMOT Architecture
4. CMOTアーキテクチャ
The CMOT (CMIP Over TCP/IP) architecture is based on the OSI management framework [15] and the models, services, and protocols developed by ISO for network management. The CMOT architecture demonstrates how the OSI management framework can be applied to a TCP/IP environment and used to manage objects in a TCP/IP network. The use of ISO protocols for the management of widely deployed TCP/IP networks will facilitate the ultimate migration from TCP/IP to ISO protocols. The concept of proxy management is introduced as a useful extension to the architecture. Proxy management provides the ability to manage network elements that either are not addressable by means of an Internet address or use a network management protocol other than CMIP.
CMOT(CMIP Over TCP/IP)アーキテクチャはネットワークマネージメントのためにISOによって開発されたOSI管理フレームワーク[15]、モデル、サービス、およびプロトコルに基づいています。 CMOTアーキテクチャはどうOSI管理フレームワークをTCP/IP環境に適用して、TCP/IPネットワークでオブジェクトを管理するのに使用できるかを示します。 ISOプロトコルの広く配布しているTCP/IPネットワークの経営の使用はTCP/IPからISOプロトコルまで究極の移行を容易にするでしょう。 プロキシ管理の概念は役に立つ拡大としてアーキテクチャに取り入れられます。 プロキシ経営者側はインターネット・アドレスによるアドレス可能でないか、またはCMIPを除いて、ネットワーク管理プロトコルを使用するネットワーク要素を管理能力に提供します。
The CMOT architecture specifies all the essential components of a network management architecture. The OSI management framework and models are used as the foundation for network management. A protocol-dependent interpretation of the Internet SMI [2] is used for defining management information. The Internet MIB [3] provides an initial list of managed objects. Finally, a means is defined for using ISO management services and protocols on top of TCP/IP transport protocols. Management applications themselves are not included within the scope of the CMOT architecture. What is currently standardized in this architecture is the minimum required for building an interoperable multivendor network management system. Applications are explicitly left as a competitive issue for network developers and providers.
CMOTアーキテクチャはネットワークマネージメントアーキテクチャのすべての必須成分を指定します。 OSI管理フレームワークとモデルはネットワークマネージメントの基礎として使用されます。 インターネットSMI[2]のプロトコル依存する解釈は、経営情報を定義するのに使用されます。 インターネットMIB[3]は管理オブジェクトの初期のリストを提供します。 最終的に、手段は、TCP/IPトランスポート・プロトコルの上でISO経営指導とプロトコルを使用するために定義されます。 管理アプリケーション自体はCMOTアーキテクチャの範囲の中に含まれていません。 現在このアーキテクチャで標準化されることは共同利用できる「マルチ-ベンダー」ネットワーク管理システムを建てるのに必要である最小限です。 アプリケーションはネットワーク開発者とプロバイダーのための競争力がある問題として明らかに残されます。
4.1. Management Models
4.1. マネジメント・モデル
The following sections indicate how the CMOT architecture applies the OSI managements models and point out any limitations the CMOT architecture has as it is currently defined in this memo.
以下のセクションは、CMOTアーキテクチャがどうOSI監理モデルを当てはまるかを示して、それが現在このメモで定義されるとき、CMOTアーキテクチャが持っているどんな制限も指摘します。
4.1.1. The Organizational Model
4.1.1. 組織的なモデル
It is beyond the scope of this memo to define the relations and interactions between different management domains. The current CMOT architecture concerns itself only with the operations and characteristics of a single domain of management. The extension of
それは、異なった管理ドメインの間の関係と相互作用を定義するためにこのメモの範囲を超えています。 現在のCMOTアーキテクチャは単に管理の単一領域の操作と特性でタッチしています。 拡大
Warrier & Besaw [Page 13] RFC 1095 CMOT April 1989
Warrier&Besaw[13ページ]RFC1095CMOT1989年4月
the mechanisms defined here to include multiple domains is left for further study.
複数のドメインを含むようにここで定義されたメカニズムはさらなる研究に残されます。
4.1.2. The Functional Model
4.1.2. 機能論的モデル
The CMOT architecture provides the foundation for carrying out management in the five functional areas (fault, configuration, performance, accounting, and security), but does not address specifically how any of these types of management are accomplished. It is anticipated that most functional requirements can be satisfied by CMIS. The greatest impact of the functional requirements in the various areas will likely be on the definition of managed objects.
CMOTアーキテクチャは、5つの機能的な領域(欠点、構成、性能、会計、およびセキュリティ)で管理を行う基礎を提供しますが、管理のこれらのタイプのどれかが明確にどう優れているかを扱いません。 CMISがほとんどの機能条件書を満たすことができると予期されます。 管理オブジェクトの定義には様々な領域の機能条件書の最もすばらしい影響がおそらくあるでしょう。
4.1.3. The Information Model
4.1.3. 情報モデル
There are two different SMI specifications that are important to the CMOT architecture. The first is the SMI currently being defined by ISO [19]. This SMI is important to the CMOT approach because the ISO management protocol CMIP has been designed with the ISO model of management information in mind. The second SMI of importance is the that defined by the IETF MIB working group for use in defining the Internet MIB [3]. This Internet SMI, which is loosely based on a simplified version of the ISO SMI, is important because the managed objects defined for TCP/IP networks to be used by CMOT are defined in terms of it. Thus, in order to make the CMOT architecture complete, it will be necessary to show how the Internet SMI maps into CMIP in such a way as to enable it to convey the management information defined in the Internet MIB. This is done in the section devoted to management information (section 5).
2つのCMOTアーキテクチャに重要な異なったSMI仕様があります。 1番目は現在ISO[19]によって定義されるSMIです。 ISO管理プロトコルCMIPが経営情報のISOモデルと共に念頭に設計されているので、このSMIはCMOTアプローチに重要です。 第2重要なSMIはインターネットMIB[3]を定義することにおける使用のためのIETF MIBワーキンググループによってそんなに定義です。 TCP/IPネットワークがCMOTによって使用されるように定義された管理オブジェクトがそれに関して定義されるので、このインターネットSMI(緩くISO SMIの簡易型のバージョンに基づいている)は重要です。 したがって、CMOTアーキテクチャを完全にするように、経営情報を伝えるのを可能にするほどSMIがCMIPにそのような方法で写像するインターネットがインターネットでどうMIBを定義したかを示しているのが必要でしょう。 経営情報(セクション5)にささげられたセクションでこれをします。
4.2. Protocol Architecture
4.2. プロトコルアーキテクチャ
The objective of the CMOT protocol architecture is to map the OSI management protocol architecture into the TCP/IP environment. The model presented here follows the OSI model at the application layer, while using Internet protocols at the transport layer. The ISO application protocols used for network management are ACSE, ROSE, and CMIP. Instead of implementing these protocols on top of the ISO presentation, session, and transport layer protocols, the protocol data units (PDUs) for ACSE, ROSE, and CMIP are carried using the Internet transport protocols UDP [20] and TCP [21]. This is made possible by means of the lightweight presentation protocol defined in RFC 1085 [13] that maps ROSE and ACSE onto TCP/UDP/IP. The use of Internet transport protocols is transparent to network management applications, since they are presented with real ISO services.
CMOTプロトコルアーキテクチャの目的はOSI管理プロトコルアーキテクチャをTCP/IP環境に写像することです。 ここに提示されたモデルはトランスポート層でインターネットプロトコルを使用している間、応用層でOSIモデルについて来ます。 ネットワークマネージメントに使用されるISOアプリケーション・プロトコルは、ACSEと、ローズと、CMIPです。 ISOプレゼンテーション、セッション、およびトランスポート層プロトコルの上でこれらのプロトコルを実装することの代わりに、ACSE、ローズ、およびCMIPのためのプロトコルデータ単位(PDUs)は、インターネットトランスポート・プロトコルのUDP[20]とTCP[21]を使用することで運ばれます。 これをTCP/UDP/IPにローズとACSEを写像するRFC1085[13]で定義された軽量のプレゼンテーションプロトコルによる可能にします。 インターネットトランスポート・プロトコルの使用は、本当のISOサービスをそれらに与えるので、ネットワークマネージメントアプリケーションにわかりやすいです。
Warrier & Besaw [Page 14] RFC 1095 CMOT April 1989
Warrier&Besaw[14ページ]RFC1095CMOT1989年4月
4.2.1. The Lightweight Presentation Layer
4.2.1. 軽量のプレゼンテーション層
Given that it is desired to put ISO application protocols on top of TCP/IP, how is this best accomplished? It is necessary somehow to fill the "gap" between the ISO protocols (ACSE and ROSE) and the Internet protocols (UDP and TCP). Two basic approaches were considered.
TCP/IPの上にISOアプリケーション・プロトコルを置くのが必要であるなら、このベストはどのように達成されますか? ISOプロトコル(ACSEとローズ)とインターネットプロトコル(UDPとTCP)の間の「ギャップ」をいっぱいにするのがどうにか必要です。 2つの基本的なアプローチが考えられました。
One possible approach [23] is to extend the ISO portion of the protocol stack down to the transport layer. The ISO Transport Protocol Class 0 (TP 0) then uses TCP instead of an ISO network protocol. Effectively, this treats TCP as a reliable network connection analogous to X.25. This approach allows us to operate "standard" ISO applications over TCP regardless of their service requirements, since all ISO services are provided. In this case, network management is just another such application. The major drawback with this approach is that full ISO presentation, session, and transport layers are expensive to implement (both in terms of processing time and memory).
1つの可能なアプローチ[23]はプロトコル・スタックのISO部分をトランスポート層まで広げることです。 そして、ISO TransportプロトコルClass0(TP0)はISOネットワーク・プロトコルの代わりにTCPを使用します。 事実上、これはX.25への類似の頼もしいネットワーク接続としてTCPを扱います。 私たちはこのアプローチでそれらのサービス要件にかかわらずTCPの上の「標準」のISOアプリケーションを操作できます、すべてのISOサービスを提供するので。 この場合、ネットワークマネージメントはただのそのようなアプリケーションです。 このアプローチがある主要な欠点は完全なISOプレゼンテーション、セッション、およびトランスポート層が実装する(処理時間とメモリに関して)ために高価であるということです。
Another approach is presented in RFC 1085. Since the service elements required for network management (ACSE, ROSE, CMISE) do not require the use of full ISO presentation layer services, it is possible to define a "streamlined" presentation layer that provides only the services required. This lightweight presentation protocol (LPP) allows the use of ISO presentation services over both TCP and UDP. This approach eliminates the necessity of implementing ISO presentation, session, and transport protocols for the sake of doing ISO network management in a TCP/IP environment. This minimal approach is justified because this non-ISO presentation protocol used is very small and very simple. Thus, the LPP defined in RFC 1085 provides a compact and easy to implement solution to the problem. The resulting CMOT protocol stack is shown in Figure 1.
別のアプローチはRFC1085に提示されます。 ネットワークマネージメント(ACSE、ローズ、CMISE)に必要であるサービス要素が完全なISOプレゼンテーション層サービスの使用を必要としないので、提供される「流線型」のプレゼンテーション層を定義するのに、サービスだけが必要であることは、可能です。 この軽量のプレゼンテーションプロトコル(LPP)はTCPとUDPの両方の上のISOプレゼンテーション・サービスの使用を許します。 TCP/IP環境におけるネットワークマネージメントをISOにすることのためにこのアプローチはISOがプレゼンテーションであると実装するという必要性、セッション、およびトランスポート・プロトコルを排除します。 使用されるこの非ISOプレゼンテーションプロトコルが非常に小さくて、非常に簡単であるので、この最小量のアプローチは正当です。 したがって、RFC1085で定義されたLPPは、問題にソリューションを実現するためにコンパクトと小休止を提供します。 結果として起こるCMOTプロトコル・スタックは図1で見せられます。
Warrier & Besaw [Page 15] RFC 1095 CMOT April 1989
Warrier&Besaw[15ページ]RFC1095CMOT1989年4月
Manager Agent
+-----------------------+ +-----------------------+
| | | |
| +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
| |ACSE| |ROSE| |CMISE| | CMIP | |ACSE| |ROSE| |CMISE| |
| +----+ +----+ +-----+ | | +----+ +----+ +-----+ |
| | | |
+-----------------------+ +-----------------------+
| LPP | | LPP |
+-----------------------+ +-----------------------+
| TCP | UDP | | TCP | UDP |
+-----------------------+ +-----------------------+
| IP | | IP |
+-----------------------+ +-----------------------+
| Link | | Link |
+-----------------------+ +-----------------------+
| |
| |
| |
=========================================================
Network
=========================================================
マネージャのエージェント+-----------------------+ +-----------------------+ | | | | | +----+ +----+ +-----+ | <、-、-、-、-、-、--、>| +----+ +----+ +-----+ | | |ACSE| |上昇しました。| |CMISE| | CMIP| |ACSE| |上昇しました。| |CMISE| | | +----+ +----+ +-----+ | | +----+ +----+ +-----+ | | | | | +-----------------------+ +-----------------------+ | LPP| | LPP| +-----------------------+ +-----------------------+ | TCP| UDP| | TCP| UDP| +-----------------------+ +-----------------------+ | IP| | IP| +-----------------------+ +-----------------------+ | リンク| | リンク| +-----------------------+ +-----------------------+ | | | | | | ========================================================= ネットワーク=========================================================
Figure 1. The CMOT Protocol Architecture
図1。 CMOTプロトコルアーキテクチャ
It is important to note that the presentation services provided by the LPP are "real" (but minimal) ISO presentation services [24]. This provides a clear migration path to "full ISO" in the future. Such a migration would be accomplished by substituting ISO protocols for the Internet protocols TCP, UDP, and IP [25], and replacing the LPP with ISO presentation and session protocols. No changes will be required in the ISO application layer protocols. For this reason, investments in application development will be well preserved.
LPPによって提供されたプレゼンテーション・サービスが「本当」の、そして、(最小量)のISOプレゼンテーション・サービス[24]であることに注意するのは重要です。 これは将来、「完全なISO」に明確な移行パスを提供します。 そのような移行は、ISOプロトコルをインターネットプロトコルTCP、UDP、およびIP[25]の代わりに用いて、LPPをISOプレゼンテーションとセッションプロトコルに取り替えることによって、達成されるでしょう。 変化は全くISO応用層プロトコルで必要でないでしょう。 この理由で、アプリケーション開発への投資はよく保持されるでしょう。
4.2.2. The Quality of Transport Service
4.2.2. 輸送サービスの品質
The quality of transport service needed for network management applications is an issue that has caused much controversy, yet it has never been resolved. There are two basic approaches: datagram- oriented and connection-oriented. There are advantages and disadvantages to both of these two approaches. While the datagram- oriented approach is simple, requires minimal code space, and can operate under conditions where connections may not be possible, the connection-oriented approach offers data reliability and provides guaranteed and consistent service to the driving application.
ネットワークマネージメントアプリケーションに必要である輸送サービスの品質が大いに物議をかもした問題である、しかし、それは一度も決議されたことがありません。 2つの基本的なアプローチがあります: データグラム指向していて接続指向です。 これらの2つのアプローチの両方への利点と難点があります。 データグラム指向のアプローチは、簡単であり、最小量のコードスペースを必要として、接続が可能でないかもしれない条件のもとで作動できますが、接続指向のアプローチは、データの信頼性を提供して、運転するアプリケーションに対する保証されて一貫したサービスを提供します。
This memo does not take sides on this issue. Rather it passes such
このメモはこの問題でどちらか一方の側につきません。 むしろそれはそのようなものを通過します。
Warrier & Besaw [Page 16] RFC 1095 CMOT April 1989
Warrier&Besaw[16ページ]RFC1095CMOT1989年4月
resolution to the network management applications, which are ultimately the point where the requirements from the underlying service need to be determined. As such, the CMOT protocol architecture provides both services. The presentation layer service allows the application to select either high or low quality service for the underlying transport. Depending on this choice, the LPP will use either UDP (low quality) or TCP (high quality) to establish the application association and carry the application data. It is important, however, for the application to be aware of the quality of service that it is using: low quality means low quality! The use of an unreliable transport like UDP necessarily puts more burden on the application.
ネットワークマネージメントアプリケーションへの解決。(結局、アプリケーションは基本的なサービスからの要件が断固とする必要があるポイントです)。 そういうものとして、CMOTプロトコルアーキテクチャは両方のサービスを提供します。 プレゼンテーション層サービスで、アプリケーションは基本的な輸送のための高いか低い質の高いサービスを選択できます。 この選択によって、LPPは、応用アソシエーションを設立して、アプリケーションデータを運ぶのに、UDP(低品質)かTCP(高品質の)のどちらかを使用するでしょう。 しかしながら、アプリケーションがそれが使用しているサービスの質を知るのは、重要です: 低品質は低品質を意味します! UDPのような頼り無い輸送の使用は必ずより多くの負担をアプリケーションに載せます。
4.3. Proxy Management
4.3. プロキシ管理
Proxy is a term that originated in the legal community to indicate an entity empowered to perform actions on behalf of another. In our context, a proxy is a manager empowered to perform actions on behalf of another manager. This may be necessary because the manager cannot communicate directly with the managed devices either for security or other administrative reasons or because of incompatible communication mechanisms or protocols. In either case, the proxy assumes the agent role with respect to the requesting manager and the manager role with respect to the managed device.
プロキシは別のものを代表して動作を実行するのに権限を与えられた実体を示すために法的な共同体で起因した用語です。 私たちの文脈では、プロキシは別のマネージャを代表して動作を実行するのに権限を与えられたマネージャです。 マネージャがセキュリティか他の管理理由か両立しないコミュニケーションメカニズムかプロトコルのために管理されたデバイスをもって直接伝達できないので、これが必要であるかもしれません。 どちらの場合ではも、プロキシは要求しているマネージャとマネージャの役割に関して管理されたデバイスに関してエージェントの役割を引き受けます。
Some network elements, such as modems or bridges, may not be able to support CMIP and all the associated protocols. In addition, such devices may not have Internet addresses. Such devices are called "limited systems". It may be possible to manage these devices using proprietary mechanisms or other standard protocols (such as the IEEE 802.1 management protocol for managing bridges). In cases where it is desirable to integrate the management of such devices with the overall CMOT management of an internet, it is necessary to use proxy management. Some network elements that are not "limited systems" as described above may still benefit from the use of proxy management. If the management protocol supported by such a system is proprietary or some standard protocol other than CMIP (such as SNMP), then CMOT proxy management can be used to integrate the management of such systems.
モデムかブリッジなどのいくつかのネットワーク要素がCMIPとすべての関連プロトコルをサポートできるかもしれないというわけではありません。 さらに、そのようなデバイスには、インターネット・アドレスがないかもしれません。 そのようなデバイスは「限られたシステム」と呼ばれます。 独占メカニズムか他の標準プロトコル(ブリッジを管理するためのIEEE802.1管理プロトコルなどの)を使用するこれらのデバイスを管理するのは可能であるかもしれません。 インターネットの総合的なCMOT管理によるそのようなデバイスの管理を統合するのが望ましい場合では、プロキシ管理を使用するのが必要です。 上で説明されるように「限られたシステム」でないいくつかのネットワーク要素がまだプロキシ管理の使用の利益を得ているかもしれません。 そのようなシステムによってサポートされた管理プロトコルが独占であるか、そして、CMIP(SNMPなどの)以外の何らかの標準プロトコル、そのようなシステムの管理を統合するのに当時のCMOTプロキシ管理を使用できます。
A proxy operates in the following manner. When a CMOT manager wants to send a request to a managed device that it cannot communicate with directly, it routes the request to the proxy. The proxy maps the CMIP request into the information schema understood by the managed device and sends the appropriate request to the managed device using the native management protocol of the device. When the proxy receives the response from the managed device, it uses CMIP to return the information to the manager that made the original request.
プロキシは以下の方法で働いています。 CMOTマネージャがそれが直接交信できない管理されたデバイスに要求を送りたがっているとき、それは要求をプロキシに発送します。 プロキシは、管理されたデバイスに解釈された情報図式にCMIP要求を写像して、デバイスの固有の管理プロトコルを使用することで適切な要求を管理されたデバイスに送ります。 プロキシが管理されたデバイスから応答を受けるとき、それは、オリジナルの要求をしたマネージャに情報を返すのにCMIPを使用します。
Warrier & Besaw [Page 17] RFC 1095 CMOT April 1989
Warrier&Besaw[17ページ]RFC1095CMOT1989年4月
The use of proxy management can be largely transparent to the requesting manager, which appears to be exchanging information directly with the selected device. The only thing that is known to the manager is that additional "instance" information is required to select a particular device managed by the proxy. Each proxy may support many managed devices, using the "instance" information to multiplex CMIP requests and responses among them. The mapping between a specific instance and an actual managed device is a local matter. (The use of the CMIP Object Instance field to select a particular system to manage by proxy is explained below in section 5.3.2.2.)
要求しているマネージャには、プロキシ管理の使用は主にわかりやすい場合があります。(そのマネージャは、直接選択されたデバイスで情報交換しているように見えます)。 マネージャにとって知られている唯一のことは追加「インスタンス」情報がプロキシによって管理された特定のデバイスを選択するのに必要であるということです。 CMIP要求と応答をそれらに多重送信するのに「インスタンス」情報を使用して、各プロキシは多くの管理されたデバイスを支えるかもしれません。 特定のインスタンスと実際の管理されたデバイスの間のマッピングは地域にかかわる事柄です。 (特定のシステムが管理するのを選択するCMIP Object Instance分野の使用は以下でセクション5.3.2で代理人を通して.2に説明されます)
A proxy may also serve as an "intermediate manager" in another less transparent sense. The proxy manager may be requested to calculate summary statistics on information gathered from many different managed systems (e.g., the average number of PDUs transmitted or the distribution of PDUs transmitted over time). The proxy may be requested to log events transmitted by the managed systems under its control and to send to the requesting manager only those events of specific types. When this use of proxy management is made, the conceptual schema for managed objects known to both the requesting manager and proxy must include definitions of these aggregate managed objects (i.e., objects that do not belong to any one managed system). How the aggregate statistics would be calculated and logging performed based on information from the different devices managed by the proxy would be part of the definition of these aggregate managed objects.
また、プロキシは「中間的マネージャ」として別のそれほど透明でない意味で勤めるかもしれません。 プロキシマネージャが多くの異なった管理されたシステムから集められた情報で要約統計量について計算するよう要求されているかもしれません(例えばPDUsの平均した数が伝わったか、またはPDUsの分配は時間がたつにつれて、伝わりました)。 管理されたシステムによってコントロールの下で伝えられたイベントを登録して、プロキシが特定のタイプのそれらのイベントを要求しているマネージャだけに送るよう要求されているかもしれません。 プロキシ管理のこの使用をするとき、要求しているマネージャとプロキシの両方に知られている管理オブジェクトのための概念スキーマはこれらの集合管理オブジェクト(すなわち、どんな管理されたシステムにも属さないオブジェクト)の定義を含まなければなりません。 集合統計が計算されていて、伐採がプロキシによって管理された異なったデバイスからの情報に基づいてどう働いたかは、これらの集合管理オブジェクトの定義の一部でしょう。
4.4. Directory Service
4.4. ディレクトリサービス
RFC 1085 specifies the use of a minimal (or "stub") directory service. It specifies how the service name for an OSI application entity is converted into an "application entity title." The application entity title is then mapped into a presentation address. The form of a service name, an application entity title, and a presentation address can be found in RFC 1085.
RFC1085は最小量(または、「スタッブ」)のディレクトリサービスの使用を指定します。 それはOSIアプリケーション実体のためのサービス名がどう「アプリケーション実体タイトル」に変換されるかを指定します。 そして、アプリケーション実体タイトルはプレゼンテーションアドレスに写像されます。 RFC1085でサービス名、アプリケーション実体タイトル、およびプレゼンテーションアドレスのフォームを見つけることができます。
5. Management Information
5. 経営情報
The description of management information has two aspects. First, a structure of management information (SMI) defines the logical structure of management information and how it is identified and described. Second, the management information base (MIB), which is specified using the SMI, defines the actual objects to be managed. The purpose of this section is to show how CMIP is used in the CMOT architecture to convey information defined in the Internet MIB.
経営情報の記述には、2つの局面があります。 まず最初に、経営情報(SMI)の構造はそれがどう経営情報と特定されて、説明されるかに関する論理構造を定義します。 2(管理情報ベース(MIB))番目は、管理されるために実際のオブジェクトを定義します。(管理情報ベースは、SMIを使用することで指定されます)。 このセクションの目的はCMIPがインターネットMIBで定義された情報を伝えるのにCMOTアーキテクチャにどう使用されるかを示していることです。
Warrier & Besaw [Page 18] RFC 1095 CMOT April 1989
Warrier&Besaw[18ページ]RFC1095CMOT1989年4月
5.1. The Structure of Management Information
5.1. 経営情報の構造
The SMI supplies the model for understanding management information, as well as templates and ASN.1 macros that can be used for defining actual management information. The following sections discuss the ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI in terms of the ISO SMI so that CMIP can be used to carry management information defined in terms of the Internet SMI.
SMIは経営情報を理解しているのにモデルを供給します、実際の経営情報を定義するのに使用できるテンプレートとASN.1マクロと同様に。 以下のセクションはISO SMI、インターネットSMI、およびインターネットSMIで定義された経営情報を運ぶのにCMIPを使用できるようにISO SMIに関してインターネットSMIを解釈する方法を論じます。
5.1.1. The ISO SMI
5.1.1. ISO SMI
The ISO SMI [19] is based on the abstraction of a "managed object" and the various kinds of relationships objects can be involved in. The following discussion does not purport to be a complete and accurate description of the latest ISO SMI work. It is intended to be a clear presentation of the basic ISO SMI concepts essential for understanding the CMIP-specific interpretation of the Internet SMI presented in section 5.3.
ISO SMI[19]は「管理オブジェクト」の抽象化とオブジェクトがかかわることができる様々な種類の関係に基づいています。 以下の議論は、最新のISO SMI仕事の完全で正確な記述であることを意味しません。 セクション5.3に示されたインターネットSMIのCMIP特有の解釈を理解しているのに、不可欠の基本のISO SMI概念の明確なプレゼンテーションであることは意図しています。
5.1.1.1. Managed Objects and Attributes
5.1.1.1. 管理オブジェクトと属性
Management Information is modeled using object-oriented techniques. All "things" in the network that are to be managed are represented in terms of managed objects. A "managed object" is an abstraction (or logical view) for the purposes of network management of a "manageable" physical or logical resource of the network. In this context, "manageable" means that a particular resource can be managed by using CMIP. Examples of managed objects are protocol entities, modems, and connections.
管理情報は、オブジェクト指向テクニックを使用することでモデル化されます。 ネットワークにおける管理されることになっているすべての「もの」が管理オブジェクトで表されます。 「管理オブジェクト」はネットワークの物理的であるか論理的な「処理しやすい」リソースのネットワークマネージメントの目的のための抽象化(または、論理的な視点)です。 この文脈、特定のリソースがそうすることができる「処理しやすい」手段では、CMIPを使用することによって、管理されてください。 管理オブジェクトに関する例は、プロトコル実体と、モデムと、接続です。
Each managed object belongs to a particular object class. An "object class" represents a collection of managed objects with the same, or similar, properties. A particular managed object existing in a particular network is defined as an "object instance" of the object class to which it belongs. Thus, an object instance represents an actual realization of an object class (i.e., a managed object of a particular class bound to specific values). An example of an object class is "transport connection." In an actual network, there are a number of managed objects (specific transport connections) that are instances of this class. In summary, a managed object type, which is called an "object class," is the collection of all actual and potential instances of that type.
各管理オブジェクトは特定のオブジェクトのクラスに属します。 「オブジェクトのクラス」は同じであるか、同様の特性で管理オブジェクトの収集を表します。 特定のネットワークで存在する特定の管理オブジェクトはそれが属するオブジェクトのクラスの「オブジェクトインスタンス」と定義されます。 したがって、オブジェクトインスタンスはオブジェクトのクラスの実際の実現を表します(すなわち、特定のクラスの管理オブジェクトは特定の値に付きました)。 オブジェクトのクラスに関する例は「輸送接続」です。 実際のネットワークには、このクラスのインスタンスである多くの管理オブジェクト(特定の輸送の接続)があります。 概要では、管理オブジェクトタイプ(「オブジェクトのクラス」と呼ばれる)はそのタイプのすべての実際の、そして、潜在的のインスタンスの収集です。
Managed objects are fully defined by specifying the "attributes" or properties the object has, the CMIS operations that can be performed on the object (e.g., M-SET, M-CREATE) and any constraints on those operations, specific actions (e.g., self-test) that can be performed on the object, events that the object can generate, and information
管理オブジェクトは、それらの操作、オブジェクトに実行できる、特定の動作(例えば、自己診断)、オブジェクトが生成することができるイベント、および情報で「属性」かオブジェクトが持っている特性と、オブジェクト(例えば、M-SET、M-CREATE)に実行できるCMIS操作とどんな規制も指定することによって、完全に定義されます。
Warrier & Besaw [Page 19] RFC 1095 CMOT April 1989
Warrier&Besaw[19ページ]RFC1095CMOT1989年4月
about various relationships the object may be involved in. All of this information relevant to a managed object is typically provided by filling in an object template.
オブジェクトがかかわるかもしれない様々な関係に関して。 オブジェクトテンプレートに記入することによって、管理オブジェクトに関連しているこの情報のすべてを通常提供します。
Managed objects contain properties that are referred to as attributes. Attributes are atomic items of information that can only be manipulated as a whole. An example of an attribute is a counter providing a specific piece of information, such as the number of packets retransmitted.
管理オブジェクトは属性と呼ばれる特性を含んでいます。 属性は全体で操ることができるだけである情報の原子項目です。 パケットの数などの特定の情報が再送されたなら、属性に関する例はカウンタです。
Each object class and attribute is assigned a unique identifier (an ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration authority.
命名の目的のためのユニークな識別子(ASN.1OBJECT IDENTIFIER)は登録局によって各オブジェクトのクラスと属性に配属されます。
5.1.1.2. Management Information Hierarchies
5.1.1.2. 経営情報階層構造
Managed objects participate in relationships with each other. There are two relationships that are of particular importance for management information: the containment relationship and the inheritance relationship. These relationships can be used to construct hierarchies of managed objects. In addition, there is another hierarchy defined by the registration process for registering identifiers for object classes and attributes.
管理オブジェクトは互いとの関係に参加します。 2つの経営情報のために特別に重要な関係があります: 封じ込め関係と継承関係。 管理オブジェクトの階層構造を構成するのにこれらの関係を使用できます。 さらに、オブジェクトのクラスと属性のための識別子を登録するための登録手続で定義された別の階層構造があります。
5.1.1.2.1. The Registration Hierarchy
5.1.1.2.1. 登録階層構造
The registration hierarchy is determined by the ASN.1 registration
tree [5] for assigning OBJECT IDENTIFIERs. An OBJECT IDENTIFIER is
an administratively assigned name composed of a series of integers
traversing a path from the root of the ASN.1 registration tree to the
node or leaf to be identified. For example, the sequence of integers
{ iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be
used to uniquely identify the CMIP standard. Each node of this tree
has an associated registration authority that determines how numbers
in the subtree defined by that node are allocated. In the context of
management, these OBJECT IDENTIFIERs are used for identifying object
classes and attributes. The registration hierarchy is not based on
any particular relationship between managed objects or between
managed objects and their attributes. It is independent of both the
inheritance and containment relationships described below. Its
purpose is simply to generate universally unique identifiers.
登録階層構造は、OBJECT IDENTIFIERsを割り当てるためにASN.1登録木[5]で決定します。 OBJECT IDENTIFIERは特定されるためにノードかASN.1登録木の根から葉まで経路を横断する一連の整数で構成された行政上割り当てられた名前です。 例えば、整数iso(1)規格(0)ips-osi-mips(9596)cmip(2)の系列、(1.0 .9596 唯一CMIP規格を特定するのに.2を)使用できます。 この木の各節には、そのノードによって定義された下位木における数がどのように割り当てられるかを決定する関連登録局があります。 管理の文脈では、これらのOBJECT IDENTIFIERsは、オブジェクトのクラスと属性を特定するのに使用されます。 登録階層構造は管理オブジェクトか管理オブジェクトとそれらの属性とのどんな特定の関係にも基づいていません。 それは継承と以下で説明された封じ込め関係の両方から独立しています。 目的は単に一般にユニークな識別子を生成することです。
5.1.1.2.2. The Containment Hierarchy
5.1.1.2.2. 包含階層
The containment hierarchy is constructed by applying the relationship "is contained in" to objects and attributes. Objects of one class may contain objects of the same or different class. Objects may also contain attributes. Attributes cannot contain objects or other
包含階層は関係が「含まれている」適用でオブジェクトと属性に構成されます。 1つのクラスのオブジェクトは同じであるか異なったクラスのオブジェクトを含むかもしれません。 また、オブジェクトは属性を含むかもしれません。 属性は何らかのオブジェクトを含むことができません。
Warrier & Besaw [Page 20] RFC 1095 CMOT April 1989
Warrier&Besaw[20ページ]RFC1095CMOT1989年4月
attributes. For example, objects of the class "transport entity" may contain objects of the class "transport connection"; an object of the class "management domain" may contain objects of the class "node." An object class that contains another object class is called the "superior" object class; an object class that is contained in another object class is called the "subordinate" object class. The containment relationships that an object may participate in are part of the definition of the object class to which that managed object belongs. All object classes (except the topmost) must have at least one possible superior in the containment tree. The definition of a class may permit it to have more than one such superior. However, individual instances of such a class are nevertheless contained in only one instance of a possible containing class.
属性。 例えば、クラス「輸送実体」のオブジェクトはクラス「輸送接続」のオブジェクトを含むかもしれません。 クラス「管理ドメイン」のオブジェクトはクラス「ノード」のオブジェクトを含むかもしれません。 もう1人のオブジェクトのクラスを含むオブジェクトのクラスは「優れた」オブジェクトのクラスと呼ばれます。 もう1人のオブジェクトのクラスに含まれているオブジェクトのクラスは「下位」のオブジェクトのクラスと呼ばれます。 オブジェクトが参加するかもしれない封じ込め関係はその管理オブジェクトが属するオブジェクトのクラスの定義の一部です。 すべてのオブジェクトのクラス(最上を除いた)には、少なくとも1人の可能な上司が封じ込め木にいなければなりません。 クラスの定義は、それにはそのような上司のより多くのひとりがいることを許可するかもしれません。 しかしながら、それにもかかわらず、そのようなクラスの個々のインスタンスは可能な含んでいるクラスの1つのインスタンスだけに含まれています。
The containment hierarchy is important because it can be used for
identifying instances of a managed object. For example, assume there
is an object class "domain" that contains an object class "node" that
contains an object class "transport entity" that contains an object
class "transport connection." A particular instance of a transport
connection can be identified by the concatenation of "instance
information" for each object class in the containment path: {
domain="organization," node="herakles," transport entity=tp4,
transport connection=<TSAP-AddressA, TSAP-AddressB> }.
包含階層は、管理オブジェクトのインスタンスを特定するのにそれを使用できるので、重要です。 例えば、オブジェクトクラス「輸送接続」を含むオブジェクトクラス「輸送実体」を含むオブジェクトクラス「ノード」を含むオブジェクトクラス「ドメイン」があると仮定してください。 封じ込め経路のそれぞれのオブジェクトのクラスのための「インスタンス情報」の連結で輸送接続の特定のインスタンスを特定できます: ドメイン=「組織」(ノード="herakles"、輸送実体=tp4)は接続=<TSAP-AddressAを輸送して、TSAP-AddressBは>です。
What constitutes appropriate "instance information" for each object class is part of the definition of that object class and is known as the "distinguished attribute(s)." A distinguished attribute is composed of an OBJECT IDENTIFIER naming the attribute and the value of the attribute. For each object class, the distinguished attributes that differentiate instances of that class are collectively called the "relative distinguished name." A sequence of relative distinguished names (one for each class in the containment path) is the "distinguished name" of a managed object. The example given above represents the distinguished name of a transport connection. The containment hierarchy is sometimes referred to as the "naming tree", because it is used to "name" a particular instance of a managed object.
それぞれのオブジェクトのクラスのための適切な「インスタンス情報」を構成することが、そのオブジェクトのクラスの定義の一部であり、「顕著な属性」として知られています。 顕著な属性は属性の属性と値を命名するOBJECT IDENTIFIERで構成されます。 それぞれのオブジェクトのクラスにおいて、そのクラスのインスタンスを差別化する顕著な属性はまとめて「相対的な分類名」と呼ばれます。 相対的な分類名(封じ込め経路の各クラスあたり1つ)の系列は管理オブジェクトの「分類名」です。 上に出された例は輸送接続の分類名を表します。 包含階層は時々「命名木」と呼ばれます、それが管理オブジェクトの特定のインスタンスを「命名すること」に使用されるので。
The containment relationship also defines an existence dependency among its components; an object or attribute can "exist" only if the containing object also "exists." Deletion of an object may result in deletion of all objects and attributes contained within it. Alternately, depending on the definition of the managed object, deletion may be refused until all contained managed objects have been deleted.
また、封じ込め関係はコンポーネントの中で存在の依存を定義します。 含んでいるオブジェクトがまた「また存在している」場合にだけ、オブジェクトか属性が「存在することができます」。 オブジェクトの削除はすべてのオブジェクトとそれの中に含まれた属性の削除をもたらすかもしれません。 管理オブジェクトの定義によって、すべての含まれた管理オブジェクトが削除されるまで、交互に、削除は拒否されるかもしれません。
Warrier & Besaw [Page 21] RFC 1095 CMOT April 1989
Warrier&Besaw[21ページ]RFC1095CMOT1989年4月
5.1.1.2.3. The Inheritance Hierarchy
5.1.1.2.3. 継承階層構造
The inheritance hierarchy is constructed by applying the relationship "inherits properties of" to object classes. An object class may inherit properties of another object class; refinement is obtained by adding additional properties. In this relationship, the parent class is called the "superclass" and the inheriting class the "subclass." For example, the class "layer entity" may be a superclass of "network entity," which in turn is a superclass of "X.25 network entity." Attributes defined for "network entity" (e.g., the number of packets sent) are automatically defined for "X.25 network entity" without having to explicitly include them in the definition for the class "X.25 network entity." Thus, inheritance serves as a shorthand for defining object classes using object-oriented methodology. Each class (except the topmost) has at least one superclass, but may have zero, one, or many subclasses. Subclasses may in turn have further subclasses, to any degree. A special object called "top" is the ultimate superclass. It has no properties of its own.
継承階層構造は関係がオブジェクトのクラスに「特性を引き継ぐ」適用で構成されます。 オブジェクトのクラスはもう1人のオブジェクトのクラスの特性を引き継ぐかもしれません。 追加特性を加えることによって、気品を得ます。 この関係では、親のクラスは"「スーパー-クラス」"と呼ばれて、「サブクラス」は世襲のクラスが呼ばれます。 例えば、クラス「層の実体」は「ネットワーク実体」の「スーパー-クラス」であるかもしれません。(順番に、それは、「X.25ネットワーク実体」の「スーパー-クラス」です)。 クラス「X.25ネットワーク実体」のための定義に明らかにそれらを含む必要はなくて、「ネットワーク実体」(例えばパケットの数は発信した)のために定義された属性は「X.25ネットワーク実体」のために自動的に定義されます。 したがって、継承はオブジェクト指向方法論を使用することでオブジェクトのクラスを定義するための速記として機能します。 各クラス(最上を除いた)には、ゼロ、1、または多くのサブクラスを持っているかもしれないのを除いて、少なくとも1つの「スーパー-クラス」があります。 サブクラスは順番にどんな度合いにもさらなるサブクラスを持っているかもしれません。 「先端」と呼ばれる特別なオブジェクトは究極の「スーパー-クラス」です。 それには、それ自身の特性が全くありません。
The inheritance hierarchy has no relevance to the naming of object instances. It is useful only insofar as it leads to a manageable and extensible technique for the definition of object classes.
継承階層構造はオブジェクトインスタンスの命名に関連性がありません。 それは、オブジェクトのクラスの定義のための処理しやすくて広げることができるテクニックに通じるので、その程度においてだけ役に立ちます。
5.1.2. The Internet SMI
5.1.2. インターネットSMI
The Internet SMI [2] is designed to be a protocol-independent SMI that can be used with both SNMP and CMIP. For this reason, it is necessary for any management protocol that uses this SMI to show how it is to be interpreted in a protocol-specific manner. This is done for CMIP in this memo.
インターネットSMI[2]は、SNMPとCMIPの両方と共に使用できるプロトコルから独立しているSMIになるように設計されています。 この理由で、それがプロトコル特有の方法でどのように解釈されることになっているかを示すのがこのSMIを使用するどんな管理プロトコルにも必要です。 このメモによるCMIPのためにこれをします。
The Internet SMI indicates both how to identify managed objects and
how to define them. The Internet SMI defines a registration subtree
rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of
registering OBJECT IDENTIFIERs to be used for uniquely identifying
managed objects. The current Internet SMI specifies the format for
defining objects in terms of an "object type" template and an
associated OBJECT-TYPE ASN.1 macro. An object type definition
contains five fields: a textual name, along with its corresponding
OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of
the object type; an access (read-only, read-write, write-only, or
not-accessible); and a status (mandatory, optional, or obsolete).
The current Internet SMI does not provide any mechanism for defining
actions or events associated with a managed object.
インターネットSMIはどう管理オブジェクトを特定するか、そして、どうそれらを定義するか両方を示します。 インターネットSMIは唯一管理オブジェクトを特定するのに使用されるためにOBJECT IDENTIFIERsを登録することのためにiso(1) org(3) dod(6)インターネット(1)で根づいている登録下位木を定義します。 現在のインターネットSMIは「オブジェクト・タイプ」テンプレートと関連OBJECT-TYPE ASN.1マクロに関してオブジェクトを定義するのに形式を指定します。 オブジェクト型定義は5つの分野を含んでいます: 対応するOBJECT IDENTIFIERに伴う原文の名前。 ASN.1構文。 オブジェクト・タイプの意味論の定義。 アクセス、(読書唯一であって、読書して書く、書く、-単に、アクセスしやすくない、)、。 そして、状態(義務的であるか、任意の、または、時代遅れの)。 現在のインターネットSMIは管理オブジェクトに関連している動作かイベントを定義するのにどんなメカニズムも提供しません。
In describing management information, the current Internet SMI does not use the notions of "object class" and "attribute" found in the ISO SMI. Only the concepts of "object type" and "object instance"
経営情報について説明する際に、現在のインターネットSMIは「オブジェクトのクラス」とISO SMIで見つけられた「属性」の概念を使用しません。 「オブジェクト・タイプ」と「オブジェクトインスタンス」の概念だけ
Warrier & Besaw [Page 22] RFC 1095 CMOT April 1989
Warrier&Besaw[22ページ]RFC1095CMOT1989年4月
are used. The Internet SMI shows how to define object types; it leaves the specification of object instances as a protocol-specific matter. The current Internet structure of management information is simpler and less rich than the corresponding ISO structure. The ISO SMI makes a distinction between simple "attributes," which can be viewed as "leaf objects" that are the lowest elements of the containment hierarchy, and composite "managed objects" that belong to an "object class" and have a structure associated with them (that is, can contain attributes). The Internet SMI does not draw this distinction; both simple and composite "objects" are defined as "object types." What structure is associated with objects in the Internet SMI is defined through the deliberate attempt to structure the lower part of the Internet registration tree according to containment principles. (Objects that are considered "attributes" of other containing objects are defined directly below them in the object registration tree.) This results in a certain lack of flexibility, since the registration hierarchy is implicitly used to define the containment hierarchy. This means that the Internet SMI does not contain a mechanism for defining containment relationships that do not happen to coincide with the registration hierarchy. In interpreting the Internet SMI for use with CMIP, it is necessary to overcome this limitation.
使用されます。 インターネットSMIは、どのようにオブジェクト・タイプを定義するかを示します。 オブジェクトインスタンスの仕様はプロトコル特有の件として残っています。 経営情報の現在のインターネット構造は、対応するISO構造より簡単であって、より豊かではありません。 ISO SMIは包含階層の最も低い原理である「葉のオブジェクト」として見なすことができる簡単な「属性」と「オブジェクトのクラス」に属して、それら(すなわち、属性を含むことができる)に関連している構造を持っている合成「管理オブジェクト」の間で区別をします。 インターネットSMIはこの区別を引き起こしません。 簡単なものと同様に合成している「オブジェクト」は「オブジェクト・タイプ」と定義されます。 封じ込め原則に従って、どんな構造がインターネットSMIのオブジェクトに関連しているかはインターネット登録木の下側の部分の構造と慎重な試みで定義されます。 (他の含有の考えられた「属性」オブジェクトであるオブジェクトはそれらの直接下でオブジェクト登録木で定義されます。) 登録階層構造が包含階層を定義するのにそれとなく使用されるので、これはある柔軟性の欠如をもたらします。 これは、インターネットSMIがたまたま登録階層構造と一致していない封じ込め関係を定義するためのメカニズムを含まないことを意味します。 CMIPとの使用のためにインターネットSMIを解釈するのにおいて、この限界を克服するのが必要です。
5.2. The Management Information Base
5.2. 管理情報ベース
The Management Information Base (MIB) is a "conceptual repository of management information." It is an abstract view of all the objects in the network that can be managed. Note that the MIB is conceptual in that it does not carry any implications whatsoever about the physical storage (main memory, files, databases, etc.) of management information. The SMI provides the guidelines for defining objects contained in the MIB.
Management Information基地(MIB)は「経営情報の概念的な倉庫」です。 それに対処できるのは、ネットワークにおけるすべてのオブジェクトの抽象的な視点です。 経営情報の物理的なストレージ(主記憶装置、ファイル、データベースなど)に関して全く少しの含意も運ばないのでMIBが概念的であることに注意してください。 SMIはMIBに含まれたオブジェクトを定義するためのガイドラインを提供します。
The CMOT approach will use the Internet MIB based on the Internet SMI described above. The first version of the Internet MIB, which is the product of the IETF MIB working group, is defined in RFC 1066 [3]. It contains objects divided into eight groups: system, interfaces, address translation, IP, ICMP, TCP, UDP, and EGP. In addition, the Internet SMI provides for future versions of the Internet MIB and a means for otherwise extending the MIB through the registration of managed objects under "private" and "experimental" branches of the object registration tree. Appendix B provides a protocol-specific interpretation of the first version of the TCP/IP MIB defined in [3] so that it can be used with CMOT. This interpretation is based on a straightforward mapping of the current Internet SMI to the ISO SMI (section 5.3).
CMOTアプローチは上で説明されたインターネットSMIに基づくインターネットMIBを使用するでしょう。 インターネットMIBの最初のバージョンはRFC1066[3]で定義されます。(MIBはIETF MIBワーキンググループの製品です)。 それは8つのグループに分割されたオブジェクトを含んでいます: システム、インタフェース、アドレス変換、IP、ICMP、TCP、UDP、およびEGP。 さらに、インターネットSMIはオブジェクト登録木の「個人的で」「実験的な」枝の下にインターネットMIBの将来のバージョンとそうでなければ、管理オブジェクトの登録でMIBを広げるための手段に備えます。 付録BはCMOTと共にそれを使用できるように[3]で定義されたTCP/IP MIBの最初のバージョンのプロトコル特有の解釈を提供します。 この解釈はISO SMI(セクション5.3)への現在のインターネットSMIの簡単なマッピングに基づいています。
The initial version of the Internet MIB concentrates on defining
インターネットMIBの初期のバージョンは定義であることに集中します。
Warrier & Besaw [Page 23] RFC 1095 CMOT April 1989
Warrier&Besaw[23ページ]RFC1095CMOT1989年4月
objects associated with various Internet protocols. It is expected that future versions of the Internet MIB and various extensions will provide a much richer set of objects to manage, including management information about a variety of network devices and systems. Thus, an expanded MIB will allow wide-ranging and powerful management using the CMOT approach.
様々なインターネットプロトコルに関連しているオブジェクト。 インターネットMIBと様々な拡大の将来のバージョンが管理するためにはるかに豊かなセットのオブジェクトを提供すると予想されます、さまざまなネットワークデバイスとシステムに関する経営情報を含んでいて。その結果、拡張MIBは、CMOTアプローチを使用することで広範囲の、そして、強力な管理を許すでしょう。
5.3. An Interpretation of the Internet SMI
5.3. インターネットSMIの解釈
In order to use CMIP to convey information defined in terms of the Internet SMI, it is necessary to show how object instances are specified and to provide the necessary structure for differentiating object class and attributes. These objectives are both met by separating the containment hierarchy used for naming objects from the registration hierarchy and by imposing an "object class" structure on the Internet SMI. Using the technique of imposing an object class structure does not replace or redefine the object definitions in the Internet MIB; it merely provides a necessary gloss or commentary on a MIB defined in terms of the Internet SMI. For example, Appendix B references the "object type" definitions found in [3], but imposes additional structure on them.
インターネットSMIで定義された情報を伝えるのにCMIPを使用するために、オブジェクトインスタンスがどう指定されるかを示していて、オブジェクトのクラスと属性を差別化するための必要な構造を提供するのが必要です。 これらの目的は、登録階層構造からオブジェクトを命名するのに使用される包含階層を切り離して、「オブジェクトのクラス」構造をインターネットSMIに課すことによって、ともに満たされます。 オブジェクトクラス構造を課すテクニックを使用するのは、インターネットMIBへのオブジェクト定義を取り替えもしませんし、再定義もしません。 それは単にインターネットSMIで定義されたMIBの必要な艶か論評を提供します。 例えば、Appendix B参照「オブジェクト・タイプ」定義は、追加構造をそれらに[3]で見つけますが、課します。
This object class definition derives from a simplified version of the OBJECT-CLASS macro defined in the ISO SMI [19]. The more complex definition is not needed for present purposes. (The object class definition presented here could be extended in the future to show what actions and events are associated with a managed object.) The object class definition has the following fields:
このオブジェクトクラス定義がISO SMI[19]で定義されたOBJECT-CLASSマクロの簡易型のバージョンに由来しています。 より複雑な定義は現在の目的に必要ではありません。 (将来、どんな動作とイベントが管理オブジェクトに関連しているかを示すためにここに提示されたオブジェクトクラス定義は広げることができました。) オブジェクトクラス定義には、以下の分野があります:
OBJECT CLASS:
------------
A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object
class, along with its corresponding OBJECT IDENTIFIER.
クラスは反対します: ------------ 対応するOBJECT IDENTIFIERに伴うオブジェクトのクラスのためにOBJECT CLASS DESCRIPTORと呼ばれた原文の名前。
Definition:
A textual description of the object class.
定義: オブジェクトのクラスの原文の記述。
Subclass Of:
The OBJECT CLASS DESCRIPTOR of the object class that is the
superclass of this object class. This field is used for indicating
the inheritance relationship.
以下のサブクラス このオブジェクトのクラスの「スーパー-クラス」であるオブジェクトのクラスのOBJECT CLASS DESCRIPTOR。 この分野は、継承関係を示すのに使用されます。
Superiors:
A list of OBJECT CLASS DESCRIPTORs of the possible superior object
classes of this object class. This field is used for indicating
the containment relationship.
上司: このオブジェクトのクラスの可能な優れたオブジェクトのクラスのOBJECT CLASS DESCRIPTORsのリスト。 この分野は、封じ込め関係を示すのに使用されます。
Warrier & Besaw [Page 24] RFC 1095 CMOT April 1989
Warrier&Besaw[24ページ]RFC1095CMOT1989年4月
Names:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
the distinguished attributes of this object class. (The OBJECT-
TYPE macro is defined in RFC 1065). Attributes listed here will
normally be present in the Attribute field of the object class
definition. This field is used for indicating what attributes
must be present in the relative distinguished name that indicates
an instance of this object class.
名前: このオブジェクトのクラスの顕著な属性であるOBJECT TYPESを特定するOBJECT DESCRIPTORsのリスト。 (OBJECT- TYPEマクロはRFC1065で定義されます。) 通常、ここに記載された属性はオブジェクトクラス定義のAttribute分野に存在するでしょう。 この分野は、どんな属性がこのオブジェクトのクラスのインスタンスを示す相対的な分類名で存在していなければならないかを示すのに使用されます。
Attributes:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
attributes of this object class. (The OBJECT-TYPE macro is defined
in RFC 1065). This field is used for indicating the attributes
that are contained in this object class.
属性: このオブジェクトのクラスの属性であるOBJECT TYPESを特定するOBJECT DESCRIPTORsのリスト。 (OBJECT-TYPEマクロはRFC1065で定義されます。) この分野は、このオブジェクトのクラスに含まれている属性を示すのに使用されます。
This object class definition satisfies our objectives for
interpreting the Internet SMI for use by CMIP. The Attributes
field shows what attributes are contained in this object class;
this makes the necessary distinction between object classes and
attributes required by CMIP. Instead of referencing an
"attribute" def inition (as is done in the ISO SMI), the
Attributes field references the "object type" definition found in
RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
The name, syntax, and access information required for attributes
is contained in the "object type" definition. Two things are
required for specifying an instance of a managed object: a
containment relationship determining a sequence of object classes
and a means for specifying the distinguished attributes for an
object class. The Superiors field makes the containment
relationship explicit; it is no longer merely a function of the
registration tree. The Names field makes it possible to indicate
the distinguished attributes for an object class required for
giving instance information. Thus, the object class definition
makes it possible to specify an object instance using CMIP.
このオブジェクトクラス定義はCMIPによる使用のためにインターネットSMIを解釈するための私たちの目的を満たします。 Attributes分野は、どんな属性がこのオブジェクトのクラスに含まれているかを示します。 これで、CMIPはオブジェクトのクラスと属性の必要な区別を必要とします。 「属性」クールなinition(ISO SMIでするように)に参照をつけることの代わりに、Attributesは「オブジェクト・タイプ」定義がRFC1065で当たって、RFC1066でインターネット標準MIBを定義するのに使用した参照をさばきます。 属性に必要である名前、構文、およびアクセス情報は「オブジェクト・タイプ」定義に含まれています。 2つのものが管理オブジェクトのインスタンスを指定するのに必要です: オブジェクトのクラスに顕著な属性を指定するためのオブジェクトのクラスと手段の系列を決定する封じ込め関係。 Superiors分野で、封じ込め関係は明白になります。 それはもう単に登録木の機能ではありません。 Names分野で、オブジェクトのクラスに、顕著な属性がインスタンス情報を教えるのに必要であることを示すのが可能になります。 したがって、オブジェクトクラス定義で、CMIPを使用することでオブジェクトインスタンスを指定するのは可能になります。
5.3.1. Object Class and Attributes
5.3.1. オブジェクトのクラスと属性
The mapping of management information to the CMIS parameters Managed Object Class and Attribute Identifier List now becomes apparent.
現在、CMISパラメタManaged Object ClassとAttribute Identifier Listへの経営情報に関するマッピングは明らかになります。
5.3.1.1. Object Class
5.3.1.1. オブジェクトのクラス
The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER assigned to the particular object class. For example, the Managed Object Class for the object class "ip" (as defined in Appendix B) is
CMIS Managed Object Classパラメタは特定のオブジェクトのクラスに配属されたOBJECT IDENTIFIERです。 例えば、オブジェクトのクラス"ip"(Appendix Bで定義されるように)のためのManaged Object Classはそうです。
{ mib 4 } = 1.3.6.1.2.1.4.
mib4は1.3と等しいです。.6 .1 .2 .1 .4。
Warrier & Besaw [Page 25] RFC 1095 CMOT April 1989
Warrier&Besaw[25ページ]RFC1095CMOT1989年4月
5.3.1.2. Attribute Identifier
5.3.1.2. 属性識別子
The CMIS Attribute Identifier List parameter is a list of Attribute Identifiers. An Attribute Identifier can be either global or local. If it is global, then it is the OBJECT IDENTIFIER assigned to the attribute (i.e., "object type") that is being indicated. For example, the global Attribute Identifier for the attribute "ipForwarding" (as defined in [3]) is
CMIS Attribute Identifier ListパラメタはAttribute Identifiersのリストです。 Attribute Identifierはグローバルであるか、または地方である場合があります。 それがグローバルであるなら、示されるのは、属性(すなわち、「オブジェクト・タイプ」)に割り当てられたOBJECT IDENTIFIERです。 例えば、属性"ipForwarding"のためのグローバルなAttribute Identifier、(定義されたコネ[3])
{ ip 1 } = 1.3.6.1.2.1.4.1.
ip1は1.3と等しいです。.6 .1 .2 .1 .4 .1。
If the Attribute Identifier is local, it is an integer that is the last component in the OBJECT IDENTIFIER identifying the object. For ipForwarding, the local Attribute Identifier is 1. In the case where the local identifier is used, the leading components of the OBJECT IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the containing object class. This is true for the interpreted Internet MIB defined in Appendix B, but may not be true generally. The local identifier is intended to be interpreted relative to the Managed Object Class field of the CMIP PDU. When a local Attribute Identifier is encountered in a CMIP PDU, the global form of the identifier is formed by prepending the OBJECT IDENTIFIER in the Managed Object Class field to the local identifier. This is valid only when scoping is not used (i.e., scoping is "baseObject"). If scoping is used, then the global form of the Attribute Identifier must be used instead of the local form.
Attribute Identifierが地方であるなら、それはオブジェクトを特定するOBJECT IDENTIFIERで最後のコンポーネントである整数です。 ipForwardingに関しては、地方のAttribute Identifierは1歳です。 ローカルの識別子が使用されている場合では、属性のためのOBJECT IDENTIFIERの主な部品は含んでいるオブジェクトのクラスのOBJECT IDENTIFIERであるに違いありません。 これは、Appendix Bで定義された解釈されたインターネットMIBに本当ですが、一般に、本当でないかもしれません。 CMIP PDUのManaged Object Class分野に比例してローカルの識別子が解釈されることを意図します。 地方のAttribute IdentifierがCMIP PDUで遭遇するとき、識別子のグローバルなフォームは、Managed Object Class分野でローカルの識別子にOBJECT IDENTIFIERをprependingすることによって、形成されます。 見るのが使用されていないときだけ(すなわち、見るのは"baseObject"です)、これは有効です。 見るのが使用されているなら、地方のフォームの代わりにAttribute Identifierのグローバルなフォームを使用しなければなりません。
5.3.2. Management Information Hierarchies
5.3.2. 経営情報階層構造
The following sections show how the three management information hierarchies are to be understood for the interpreted Internet SMI.
以下のセクションは、3つの経営情報階層構造が解釈されたインターネットSMIのためにどのように理解されるかことであることを示します。
5.3.2.1. The Registration Hierarchy
5.3.2.1. 登録階層構造
The registration hierarchy is the global object registration tree described in [2]. It is used merely for assigning identifiers for object classes and attributes (i.e., "object types" in RFC 1065).
登録階層構造は[2]で説明されたグローバルなオブジェクト登録木です。 それは、単にオブジェクトのクラスと属性(すなわち、RFC1065の「オブジェクト・タイプ」)のための識別子を割り当てるのに使用されます。
5.3.2.2. The Containment Hierarchy
5.3.2.2. 包含階層
As described above, the containment hierarchy is used to specify an object instance. The Names field of the object class definition contains the distinguished attributes for the object class. The OBJECT IDENTIFIER naming the "attribute" together with its value is called an attribute value assertion. A set of attribute value assertions (one for each distinguished attribute) is the relative distinguished name associated with that object class. The sequence of relative distinguished names for each of the object classes in the
上で説明されるように、包含階層はオブジェクトインスタンスを指定するのに使用されます。 オブジェクトクラス定義のNames分野はオブジェクトのクラスに、顕著な属性を含んでいます。 値と共に「属性」を命名するOBJECT IDENTIFIERは属性値主張と呼ばれます。 1セットの属性値主張(それぞれの顕著な属性あたり1つ)はそのオブジェクトのクラスに関連している相対的な分類名です。 それぞれのオブジェクトのための相対的な分類名の系列は中で属します。
Warrier & Besaw [Page 26] RFC 1095 CMOT April 1989
Warrier&Besaw[26ページ]RFC1095CMOT1989年4月
containment hierarchy to which a managed object belongs is the distinguished name of the object. An object instance is fully specified by a distinguished name.
管理オブジェクトが属する包含階層はオブジェクトの分類名です。 オブジェクトインスタンスは分類名によって完全に指定されます。
Let us take a concrete example from Appendix B. How would we represent an instance of an entry in the IP routing table? We begin by examining the object class in question (ipRouteEntry) and use the Superiors field to find the superior class in the containment hierarchy (ipRoutingTable). This process continues until we construct the following containment path of object classes: system, ip, ipRoutingTable, ipRouteEntry. Now for each of these object classes, we inspect the Names field to find the distinguished attribute for that object class. If no Names field is present (as is the case for "ip" and "ipRoutingTable"), then no instance information is required at that level. Both "system" and "ipRouteEntry" have Name fields to show what information is expected at that level. With this information, we can construct the following distinguished name specifying an instance of an IP routing table entry:
HowがそうするAppendix B.から具体的な実例で取りましょう。私たちはIP経路指定テーブルにエントリーのインスタンスを表しますか? 私たちは、問題のオブジェクトのクラス(ipRouteEntry)を調べることによって始まって、包含階層(ipRoutingTable)で優れたクラスを見つけるのにSuperiors分野を使用します。 私たちがオブジェクトのクラスの以下の封じ込め経路を構成するまで、このプロセスは持続します: システム、ip、ipRoutingTable、ipRouteEntry。 現在、それぞれのこれらのオブジェクトのクラスがないかどうか、私たちは、そのオブジェクトのクラスに関して顕著な属性を見つけるためにNames分野を点検します。 どんなNames分野も存在していないなら("ip"と"ipRoutingTable"のためのケースのような)、インスタンス情報は全くそのレベルで必要ではありません。 「システム」と"ipRouteEntry"の両方には、どんな情報がそのレベルで予想されるかを示すName分野があります。 この情報で、私たちはIP経路指定テーブルエントリーのインスタンスを指定する以下の分類名を構成できます:
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName { -- system
attributeValueAssertion {
attributeType { cmotSystemID }
attributeValue "gateway1.acme.com"
}
},
relativeDistinguishedName { -- ipRouteEntry
attributeValueAssertion {
attributeType { ipRouteDest }
attributeValue 10.0.0.51
}
}
}
}
baseManagedObjectInstancedistinguishedName、relativeDistinguishedName、--、システムattributeValueAssertion、attributeType cmotSystemID、attributeValue"gateway1.acme.com"、relativeDistinguishedName、--、ipRouteEntry attributeValueAssertion、attributeType ipRouteDest、attributeValue10.0.0、.51
If the system instance information is not present, then it is assumed to be the system with which the management association is established (i.e., the system receiving the request).
システムインスタンス情報が存在していないなら、それは管理協会が設立されるシステム(すなわち、要求を受け取るシステム)であると思われます。
Note that the object instance tree can contain components of the distinguished name that are outside the managed system (node). This enables referencing of objects across management domains (there could be an object class "domain") and across a collection of nodes. In a network where several intermediate managers may be involved in a request, each intermediate manager can use the "system" portion of
オブジェクトインスタンス木が管理されたシステム(ノード)の外にある分類名のコンポーネントを含むことができることに注意してください。 これは管理ドメイン(オブジェクトクラス「ドメイン」があるかもしれない)の向こう側にノードの収集の向こう側にオブジェクトの参照箇所を可能にします。 数人の中間的マネージャが要求にかかわるかもしれないところでは、それぞれの中間的マネージャが「システム」部分を使用できるネットワークで
Warrier & Besaw [Page 27] RFC 1095 CMOT April 1989
Warrier&Besaw[27ページ]RFC1095CMOT1989年4月
the name to determine where to send a request or result. This technique of naming treats each intermediate managing system as a proxy manager. The proxy manager resolves the address of the next node in the chain and may use a different protocol to transfer the request or result. Thus, the "system" instance information can be used to name devices being managed by proxy.
要求か結果をどこに送るかを決定する名前。 命名のこのテクニックはそれぞれの中間的管理システムをプロキシマネージャとして扱います。 プロキシマネージャは、チェーンで次のノードのアドレスを決議して、要求か結果を移すのに異なったプロトコルを使用するかもしれません。 したがって、代理人を通して管理されるとデバイスを命名するのに「システム」インスタンス情報を使用できます。
5.3.2.3. The Inheritance Hierarchy
5.3.2.3. 継承階層構造
The Internet SMI does not use the inheritance relationship. The "Subclass Of" field is present in the object class definition to show how the inheritance relationship would be represented and to allow for future extensibility. It is not used for any of the object classes defined in Appendix B.
インターネットSMIは継承関係を使用しません。 「」 分野のサブクラスは継承関係がどう表されるだろうかを示していて、将来の伸展性を考慮するオブジェクトクラス定義で存在しています。 それはAppendix Bで定義されたオブジェクトのクラスのいずれにも使用されません。
5.4. Scoping, Filtering, and Synchronization
5.4. 見る、フィルタリング、および同期
Within some services, CMIS provides additional capabilities that are related to the SMI. These are the scoping, filtering, synchronization, and linked-reply facilities. The presence of these facilities are indicated by the Multiple Object Selection Functional Unit defined in CMIS [11].
いくつかのサービスの中では、CMISはSMIに関連する追加能力を提供します。 これらは見る、フィルタリング、同期、および繋がっている回答施設です。 これらの施設の存在はCMIS[11]で定義されたMultiple Object Selection Functional Unitによって示されます。
These facilities provide the manager with the ability to operate on a collection of managed objects, rather than a single object. The selection of multiple objects occurs in two phases: scoping and filtering. Scoping is used to identify the managed objects to which a filter is to be applied. Then filtering is used to select a subset of managed objects that satisfy certain conditions. If scoping is not used, only the "base" managed object indicated by the CMIS Managed Object Class parameter is implied. An example of the use of scoping and filtering for selecting a particular managed object (a table entry) is given in one of the sample protocol exchanges found in Appendix C.
これらの施設は単一のオブジェクトよりむしろ管理オブジェクトの収集を作動させる能力をマネージャに提供します。 複数のオブジェクトの品揃えは二相で起こります: 見て、フィルターにかけます。 見ることは、フィルタが適用されていることになっている管理オブジェクトを特定するのに使用されます。 そして、フィルタリングは、ある状態を満たす管理オブジェクトの部分集合を選択するのに使用されます。 見るのが使用されていないなら、CMIS Managed Object Classパラメタによって示された「ベース」管理オブジェクトだけが含意されます。 特定の管理オブジェクトを選択するために(テーブル項目)を見て、フィルターにかけることの使用に関する例はAppendix Cで見つけられたサンプルプロトコル交換の1つで出されます。
5.4.1. Scoping
5.4.1. 見ます。
Scoping is meant to be understood in terms of the containment hierarchy. A position at a certain level of the containment tree is defined by the CMIS Managed Object Class parameter. The CMIS Scope parameter is then interpreted relative to this "base" managed object (defined by both object class and object instance). The Scope parameter can be used to select the base object alone, all managed objects in the entire subtree (of the containment tree) below the base object, or all managed objects in the "n"th level (n = 1, 2, 3,...) below the base object.
見ることは包含階層で理解されることになっています。 封じ込め木のあるレベルにおける立場はCMIS Managed Object Classパラメタによって定義されます。 そして、CMIS Scopeパラメタはこの「ベース」管理オブジェクト(オブジェクトのクラスとオブジェクトインスタンスの両方で、定義される)に比例して解釈されます。 ベースオブジェクトだけ、ベースオブジェクトの下の全体の下位木(封じ込め木の)におけるすべての管理オブジェクト、または「n」のすべての管理オブジェクトを選択するのにScopeパラメタを使用できる、ベースオブジェクトの下で(n=1、2、3、…)を第平らにしてください。
Warrier & Besaw [Page 28] RFC 1095 CMOT April 1989
Warrier&Besaw[28ページ]RFC1095CMOT1989年4月
5.4.2. Filtering
5.4.2. フィルタリング
Within the objects selected as a result of the scope parameter, it is possible to further refine the selection of managed objects through the use of filtering. Filtering provides the ability to select a subset of these objects based on conditions applied to attributes (e.g., IP routing table entries with the "ipRouteAge > 100") and logical operations (and, or, not).
範囲パラメタの結果、選択されたオブジェクトの中では、さらにフィルタリングの使用による管理オブジェクトの品揃えを洗練するのは可能です。 そして、フィルタリングが属性(例えば、「ipRouteAge>100」とのIP経路指定テーブルエントリー)と論理演算に適用された状態に基づくこれらのオブジェクトの部分集合を選択する能力を提供する、()
5.4.3. Synchronization
5.4.3. 同期
When multiple managed objects have been selected using scoping and filtering, the question of synchronization across object instances (such as multiple IP routing table entries) arises. The two possible choices are "best effort" and "atomic." If "best effort" synchronization is selected, the failure to apply an operation (e.g., M-SET) to one instance of an object does not affect the effort to apply this operation to other instances of the object. If "atomic" synchronization is selected, then the operation is either performed on all object instances selected or none. The default synchronization is best effort.
複数の管理オブジェクトが見るのとフィルタリングを使用することで選択されたとき、オブジェクトインスタンス(複数のIP経路指定テーブルエントリーなどの)の向こう側の同期の問題は起こります。 2つの可能な選択が、「ベストエフォート型」で「原子です」。 「ベストエフォート型」の同期が選択されて、操作(例えば、M-SET)をオブジェクトの1つのインスタンスに適用しない場合、オブジェクトの他のインスタンスにこの操作を適用する取り組みに影響しません。 「原子」の同期が選択されるなら、操作はインスタンスが選択したすべてのオブジェクトかなにもに実行されます。 デフォルト同期はベストエフォート型です。
5.4.4. Linked Replies
5.4.4. 繋がっている回答
If the reply to a single request for a set of managed objects results in more than one managed object being returned, all of these managed objects cannot be returned together in a single CMIP response PDU. The reason for this is that the structure of the CMIP response PDU only has a single field for containing object instance information. Since each managed object has its own instance information, each managed object must be returned in a separate CMIP PDU. In such a case, the CMIP Linked Reply PDU is used. The Linked Reply PDU provides a means of associating each of the multiple replies with the original request that generated them. Thus, a single CMIP Get Request PDU that uses scoping and filtering would result in zero or more CMIP Linked Reply PDUs being returned before a final CMIP Get Result PDU.
1セットの管理オブジェクトを求めるただ一つの要求に関する回答が返される1つ以上の管理オブジェクトをもたらすなら、ただ一つのCMIP応答PDUでこれらの管理オブジェクトのすべてを一緒に返すことができません。 この理由はCMIP応答PDUの構造にはオブジェクトインスタンス情報を含むためのただ一つの分野があるだけであるということです。 各管理オブジェクトにはそれ自身のインスタンス情報があるので、別々のCMIP PDUで各管理オブジェクトを返さなければなりません。 このような場合には、CMIP Linked Reply PDUは使用されています。 Linked Reply PDUはそれらを生成したオリジナルの要求にそれぞれの複数の回答を関連づける手段を提供します。 したがって、見るのとフィルタリングを使用する独身のCMIP Get Request PDUは最終的なCMIP Get Result PDUの前に返されるゼロか、より多くのCMIP Linked Reply PDUsをもたらすでしょう。
A linked reply can also be used to segment a CMIP response pertaining to a single managed object. This would only be necessary if UDP is being used as the underlying transport and it is not possible to return all the information requested about the managed object in a single response PDU subject to the size limitations described in section 10.2.
また、ただ一つの管理オブジェクトに関係するCMIP応答を区分するのに繋がっている回答を使用できます。 UDPが基本的な輸送として使用される場合にだけ、これが必要でしょう、そして、サイズ制限を条件としたPDUがセクション10.2で説明したただ一つの応答における管理オブジェクトに関して要求されたすべての情報を返すのは可能ではありません。
5.5. Accessing Tables
5.5. テーブルにアクセスします。
This section explains how to use the interpreted Internet SMI and MIB
このセクションは解釈されたインターネットSMIとMIBを使用する方法を説明します。
Warrier & Besaw [Page 29] RFC 1095 CMOT April 1989
Warrier&Besaw[29ページ]RFC1095CMOT1989年4月
to access tables.
テーブルにアクセスするために。
5.5.1. Accessing Whole Tables
5.5.1. 全体のテーブルにアクセスします。
A whole table is accessed by specifying the object class of the table, indicating a scoping level of one, and not providing an attribute identifier list. The CMIS standard [11] specifies that if the attribute identifier parameter is not present, then all attribute identifiers are assumed. The following CMIS parameters would be used to return the entire TCP connection table:
テーブルのオブジェクトのクラスを指定することによって、全体のテーブルはアクセスされます、見ているレベルの1つを示して、属性名前の並びを提供しないで。 CMIS規格[11]は、属性識別子パラメタが存在していないならすべての属性識別子が想定されると指定します。 以下のCMISパラメタは全体のTCP接続テーブルを返すのに使用されるでしょう:
Object Class: { tcpConnTable }
Object Instance: "empty" (unless proxy management is used)
Scope: oneLevel(1)
Filter: not present
Attribute Identifier List: not present
クラスは反対します: 以下を例証しますtcpConnTableが、反対する。 「空」(プロキシ管理が使用されていない場合)の範囲: oneLevel(1)は以下をフィルターにかけます。 現在のAttribute Identifier Listでない: 存在でない
By scoping one level below "tcpConnTable," all managed objects of the class "tcpConnEntry" are selected. (The object class "tcpConnEntry" is the only object class one level below the object class "tcpConnTable" in the containment hierarchy.) The absence of an attribute identifier list signals that all attributes of the managed object are to be returned (i.e., all fields of the TCP connection table entry).
"tcpConnTable"の下で1つのレベルを見ることによって、クラス"tcpConnEntry"のすべての管理オブジェクトが選択されます。 (オブジェクトのクラス"tcpConnEntry"は包含階層のオブジェクトのクラス"tcpConnTable"の下で唯一のオブジェクトクラス1レベルです。) 属性名前の並びの欠如は、管理オブジェクトのすべての属性が(TCP接続テーブル項目のすなわちすべての分野)が返されることであることを示します。
In reply to this request, each entry of the table will be returned in a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU). Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and the appropriate Object Instance information for that entry, as well as an Attribute List giving the values of each of the fields of the table entry.
この要求に対して、別々のCMIP PDU(Linked Reply PDUかGet Result PDUのどちらか)でテーブルの各エントリーを返すでしょう。 それぞれの回答CMIP PDUはObject Class"tcpConnEntry"とそのエントリーのための適切なObject Instance情報を指定するでしょう、それぞれのテーブル項目の分野の値を与えるAttribute Listと同様に。
5.5.2. Accessing Table Entries
5.5.2. テーブル項目にアクセスします。
An entire table entry is accessed by specifying the object class of the table entry, providing a distinguished name specifying the instance of the table entry, and not providing an attribute identifier list. As seen above, the absence of the attribute identifier list parameter indicates that all attributes are assumed. The absence of a scope parameter indicates that the base managed object class is intended. The following CMIS parameters would be used to return the entire IP routing table entry for which the field "ipRouteDest" has the value 10.0.0.51:
テーブル項目のオブジェクトのクラスを指定することによって、全体のテーブル項目はアクセスされます、テーブル項目のインスタンスを指定して、属性名前の並びを提供しないことで分類名を提供して。 上が見られるように、属性名前の並びパラメタの欠如は、すべての属性が想定されるのを示します。 範囲パラメタの欠如は、ベース管理オブジェクトのクラスが意図するのを示します。 以下のCMISパラメタが分野"ipRouteDest"が値を持っている全体のIP経路指定テーブルエントリーを返すのに使用されるだろう、10.0、.0、.51、:
Object Class: { ipRouteEntry }
Object Instance: { ipRouteDest, 10.0.0.51 }
Scope: not present
Filter: not present
クラスは反対します: 以下を例証しますipRouteEntryが、反対する。 ipRouteDest、10.0、.0、.51、範囲: 現在のFilterでない: 存在でない
Warrier & Besaw [Page 30] RFC 1095 CMOT April 1989
Warrier&Besaw[30ページ]RFC1095CMOT1989年4月
Attribute Identifier List: not present
名前の並びを結果と考えてください: 存在でない
The result is returned in a single CMIP Get Result PDU with an attribute list consisting of all of the attributes (i.e., fields) of the table entry and their corresponding values.
属性リストがテーブル項目とそれらの換算値の属性(すなわち、分野)のすべてから成っていて、結果は独身のCMIP Get Result PDUで返されます。
If the object class field refers to a table entry and no instance information is provided to select a particular entry, then a "noSuchObjectInstance" CMIP error should be returned.
オブジェクト類体がテーブル項目について言及して、特定のエントリーを選択するためにインスタンス情報を全く提供しないなら、"noSuchObjectInstance"CMIP誤りを返すべきです。
Warrier & Besaw [Page 31] RFC 1095 CMOT April 1989
Warrier&Besaw[31ページ]RFC1095CMOT1989年4月
Part II: Protocol Agreements
パートII: プロトコル協定
6. CMOT Protocol Overview
6. CMOTプロトコル概要
This part of the document is a specification of the protocols of the CMOT architecture. Contained herein are the agreements required to implement interoperable network management systems using these protocols. The protocol suite defined by these implementors' agreements will facilitate communication between equipment of different vendors, suppliers, and networks. This will allow the emergence of powerful multivendor network management based on ISO models and protocols.
ドキュメントのこの部分はCMOTアーキテクチャのプロトコルの仕様です。 ここに含まれているのは、これらのプロトコルを使用することで共同利用できるネットワーク管理システムを実装するのに必要である協定です。 これらの実装者間協定で定義されたプロトコル群は異なったベンダー、供給者、およびネットワークの設備のコミュニケーションを容易にするでしょう。 これはISOモデルとプロトコルに基づく強力な「マルチ-ベンダー」ネットワークマネージメントの出現を許容するでしょう。
The choice of a set of protocol standards together with further agreements needed to implement those standards is commonly referred to as a "profile." The selection policy for the CMOT profile is to use existing standards from the international standards community (ISO and CCITT) and the Internet community. Existing ISO standards and draft standards in the area of OSI network management form the basis of this CMOT profile. Other ISO application layer standards (ROSE and ACSE) are used to support the ISO management protocol (CMIP). To ensure interoperability, certain choices and restrictions are made here concerning various options and parameters provided by these standards. Internet standards are used to provide the underlying network transport. These agreements provide a precise statement of the implementation choices made for implementing ISO network management standards in TCP/IP-based internets.
それらの規格を実装するのに必要であるさらなる協定に伴う1セットのプロトコル標準の選択は一般的に「プロフィール」と呼ばれます。 CMOTプロフィールのための選択方針は世界規格共同体(ISOとCCITT)とインターネットコミュニティから既存の規格を使用することです。 OSIネットワークマネージメントの領域の既存のISO規格と草稿規格はこのCMOTプロフィールの基礎を形成します。 他のISO応用層規格(ローズとACSE)は、ISOが管理プロトコル(CMIP)であるとサポートするのに使用されます。 相互運用性を確実にするために、ここでこれらの規格によって提供された様々なオプションとパラメタに関して、ある選択と制限をします。 インターネット標準は、基本的なネットワーク輸送を提供するのに使用されます。 これらの協定はISOネットワークマネージメントが規格であると実装するためにされた実装選択の的確な陳述をTCP/IPベースのインターネットに提供します。
In addition to the Netman working group, there are at least two other bodies actively engaged in defining profiles for interoperable OSI network management: the National Institute of Science and Technology (NIST) Network Management Special Interest Group (NMSIG) and the OSI Network Management Forum. Both of these groups are similar to the Netman working group in that they are each defining profiles for using ISO standards for network management. Both differ in that they are specifying the use of underlying ISO protocols, while the Netman working group is concerned with using OSI management in TCP/IP networks. In the interest of greater future compatibility, the Netman working group has attempted to make the CMOT profile conform as closely as possible to the ongoing work of these two bodies.
Netmanワーキンググループに加えて、活発に共同利用できるOSIネットワークマネージメントのためのプロフィールを定義するのに従事している他の少なくとも2つのボディーがあります: 科学技術(NIST)ネットワークマネージメント特殊利益集団(NMSIG)の国家の研究所とOSIネットワークマネージメントフォーラム。 これらのグループの両方がそれぞれネットワークマネージメントのISO規格を使用するためのプロフィールを定義しているという点においてNetmanワーキンググループと同様です。 両方が彼らが基本的なISOプロトコルの使用を指定しているという点において異なります、NetmanワーキンググループはTCP/IPネットワークにOSI管理を使用するのに関係がありますが。 より大きい将来の互換性のために、Netmanワーキンググループは、CMOTプロフィールがこれらの2つのボディーの進行中の仕事にできるだけ密接に一致させるのを試みました。
6.1. The CMOT Protocol Suite
6.1. CMOTプロトコル群
The following seven protocols compose the CMOT protocol suite: ISO ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation protocol (LPP), UDP, TCP, and IP. The relation of these protocols to each other is briefly summarized in Figure 2.
以下の7つのプロトコルがCMOTプロトコル群を構成します: ISO ACSE、ISO DIS ROSE、ISO DIS CMIP、軽量のプレゼンテーションプロトコル(LPP)、UDP、TCP、およびIP。 互いにこれらのプロトコルの関係は図2に簡潔にまとめられます。
Warrier & Besaw [Page 32] RFC 1095 CMOT April 1989
Warrier&Besaw[32ページ]RFC1095CMOT1989年4月
+----------------------------------------------+
| Management Application Processes |
+----------------------------------------------+
+----------------------------------------------+ | 管理アプリケーション・プロセス| +----------------------------------------------+
+-------------------+
| CMISE |
| ISO DIS 9595/9596 |
+-------------------+
+-------------------+ | CMISE| | ISO不-9595/9596| +-------------------+
+------------------+ +--------------------+
| ACSE | | ROSE |
| ISO IS 8649/8650 | | ISO DIS 9072-1/2 |
+------------------+ +--------------------+
+------------------+ +--------------------+ | ACSE| | 上昇しました。| | ISOは8649/8650です。| | ISOは9072-1/2をけなします。| +------------------+ +--------------------+
+-----------------------------------------------+
| Lightweight Presentation Protocol (LPP) |
| RFC 1085 |
+-----------------------------------------------+
+-----------------------------------------------+ | ライト級プレゼンテーションプロトコル(LPP)| | RFC1085| +-----------------------------------------------+
+------------------+ +--------------------+
| TCP | | UDP |
| RFC 793 | | RFC 768 |
+------------------+ +--------------------+
+------------------+ +--------------------+ | TCP| | UDP| | RFC793| | RFC768| +------------------+ +--------------------+
+-----------------------------------------------+
| IP |
| RFC 791 |
+-----------------------------------------------+
+-----------------------------------------------+ | IP| | RFC791| +-----------------------------------------------+
Figure 2. The CMOT Protocol Suite
図2。 CMOTプロトコル群
6.2. Conformance Requirements
6.2. 順応要件
A CMOT-conformant system must implement the following protocols: ACSE, ROSE, CMIP, LPP, and IP. A conformant system must support the use of the LPP over either UDP or TCP. The use of the LPP over both UDP and TCP on the same system may be supported. A conformant system need not support all CMIS operations. A conformant system must, however, support at least one of the functional unit groups (indicating a set of supported services) defined in section 7.1.3. The service and protocol selections are described in greater detail in the following sections.
CMOT-conformantシステムは以下のプロトコルを実装しなければなりません: ACSE、ローズ、CMIP、LPP、およびIP。 conformantシステムはUDPかTCPのどちらかの上でLPPの使用をサポートしなければなりません。 同じシステムの上のUDPとTCPの両方の上のLPPの使用はサポートされるかもしれません。 conformantシステムは、すべてのCMISが操作であるとサポートする必要はありません。 しかしながら、conformantシステムは少なくともグループ(1セットのサポートしているサービスを示す)がセクション7.1.3で定義した機能的なユニットの1つをサポートしなければなりません。 サービスとプロトコル選択は以下のセクションで詳細によりすばらしい説明されます。
6.3. Abstract Syntax Notation
6.3. 抽象構文記法
The abstract syntax notation for all of the application service elements of the CMOT protocol suite is Abstract Syntax Notation One (ASN.1) [5]. The LPP is also defined using ASN.1. The basic
CMOTプロトコル群の応用サービス要素のすべてのための抽象構文記法は抽象的なSyntax Notation One(ASN.1)[5]です。 また、LPPは、ASN.1を使用することで定義されます。 基本的
Warrier & Besaw [Page 33] RFC 1095 CMOT April 1989
Warrier&Besaw[33ページ]RFC1095CMOT1989年4月
encoding rules used for ASN.1 are specified in [6]. Both definite- length and indefinite-length encodings are expressly permitted.
ASN.1に使用される符号化規則は[6]で指定されます。 明確な長さと無期長さのencodingsの両方が明白に受入れられます。
7. Common Management Information Service Element
7. 共通管理情報サービス要素
The Common Management Information Service Element (CMISE) is specified in two ISO documents. The service definition for the Common Management Information Service (CMIS) is given in ISO DIS 9595-2 [11]. The protocol specification for the Common Management Information Protocol (CMIP) is found in ISO DIS 9596-2 [12].
Common Management情報Service Element(CMISE)は2通のISOドキュメントで指定されます。 ISO DIS9595-2[11]でCommon Management情報Service(CMIS)のためのサービス定義を与えます。 共通管理情報プロトコル(CMIP)のためのプロトコル仕様はISO DIS9596-2[12]で見つけられます。
7.1. CMIS Services
7.1. CMISサービス
7.1.1. CMIS Services Overview
7.1.1. CMISサービス概要
All of the CMIS services listed in Table 1 are allowed with the CMOT approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET, M-SET, M-ACTION, M-CREATE, and M-DELETE. The specific services supported by a system will be determined by the functional unit group or groups to which a system belongs.
Table1に記載されたCMISサービスのすべてがCMOTアプローチで許容されています: M初期化、Mセット、M動作がM作成して、M削除するM得ているM終わっていて、M中止になっているMイベントレポート。 システムで後押しされている特定のサービスはシステムが属する機能的なユニットグループかグループによって決定されるでしょう。
7.1.2. Functional Units
7.1.2. 機能的なユニット
The CMIS services supported are designated in terms of functional units [11]. Each functional unit corresponds to the invoker or performer aspect of a particular service. (The terms "invoker" and "performer" are taken from ROSE and refer to the caller of and responder to a remote operation, respectively.) The "stand alone" functional units associated with each of the management services are given in Table 2 as functional units 0-17. The number following the name of each functional unit in the table is defined by CMIP [12] to identify that particular functional unit. The functional units are used by the CMISE-service-user at the time of association establishment to indicate which services it is willing to support.
サービスがサポートしたCMISは機能的なユニット[11]で指定されます。 それぞれの機能的なユニットは特定にサービスの呼び出し元かパフォーマー局面に文通されます。 そして、(用語「呼び出し元」と「パフォーマー」がローズから連れて行かれて、訪問者について言及する、それぞれリモート操作への応答者、) 機能的なユニット0-17としてTable2でそれぞれの経営指導に関連している「スタンドアロン」機能的なユニットを与えます。 テーブルでそれぞれの機能的なユニットの名前に従う数は、その特定の機能的なユニットを特定するためにCMIP[12]によって定義されます。 機能的なユニットは、協会設立時点で、どのサービスをサポートするかを構わないそれが、思っている示すのにCMISE-サービス利用者によって使用されます。
Warrier & Besaw [Page 34] RFC 1095 CMOT April 1989
Warrier&Besaw[34ページ]RFC1095CMOT1989年4月
+---------------------------------+------------------------+------+
| Functional Unit | Service Primitives | Mode |
+---------------------------------+------------------------+------+
| conf. event report invoker(0) | M-EVENT-REPORT Req/Conf| C |
| conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C |
| event report invoker(2) | M-EVENT-REPORT Req | U |
| event report performer(3) | M-EVENT-REPORT Ind | U |
| confirmed get invoker(4) | M-GET Req/Conf | N/A |
| confirmed get performer(5) | M-GET Ind/Rsp | N/A |
| confirmed set invoker(6) | M-SET Req/Conf | C |
| confirmed set performer(7) | M-SET Ind/Rsp | C |
| set invoker(8) | M-SET Req | U |
| set performer(9) | M-SET Ind | U |
| confirmed action invoker(10) | M-ACTION Req/Conf | C |
| confirmed action performer(11) | M-ACTION Ind/Rsp | C |
| action invoker(12) | M-ACTION Req | U |
| action performer(13) | M-ACTION Ind | U |
| confirmed create invoker(14) | M-CREATE Req/Conf | N/A |
| confirmed create performer(15) | M-CREATE Ind/Rsp | N/A |
| confirmed delete invoker(16) | M-DELETE Req/Conf | N/A |
| confirmed delete performer(17) | M-DELETE Ind/Rsp | N/A |
| multiple reply(18) | Linked Identification | N/A |
| multiple object selection(19) | Scope, Filter, Sync. | N/A |
| extended service(20) | Extended Presentation | N/A |
+---------------------------------+------------------------+------+
C = confirmed, U = non-confirmed, N/A = not applicable
+---------------------------------+------------------------+------+ | 機能的なユニット| サービス基関数| モード| +---------------------------------+------------------------+------+ | confイベントレポート呼び出し元(0)| イベントが報告するM Req/Conf| C| | confイベントレポートパフォーマー(1)| イベントが報告するMインディアン座/Rsp| C| | イベントレポート呼び出し元(2)| イベントが報告するM Req| U| | イベントレポートパフォーマー(3)| イベントが報告するMインディアン座| U| | 確認されて、呼び出し元(4)を手に入れてください。| Req/ConfをM手に入れてください。| なし| | 確認されて、パフォーマー(5)を手に入れてください。| インディアン座/RspをM手に入れてください。| なし| | 確認されたセット呼び出し元(6)| MセットReq/Conf| C| | 確認されたセットパフォーマー(7)| Mセットインディアン座/Rsp| C| | 呼び出し元(8)を設定してください。| MセットReq| U| | パフォーマー(9)を設定してください。| Mセットインディアン座| U| | 確認された動作呼び出し元(10)| M動作Req/Conf| C| | 確認された動作パフォーマー(11)| M動作インディアン座/Rsp| C| | 動作呼び出し元(12)| M動作Req| U| | 動作パフォーマー(13)| M動作インディアン座| U| | 確認されて、呼び出し元(14)を創造してください。| Req/ConfをM作成してください。| なし| | 確認されて、パフォーマー(15)を創造してください。| インディアン座/RspをM作成してください。| なし| | 確認されて、呼び出し元(16)を削除してください。| Req/ConfをM削除してください。| なし| | 確認されて、パフォーマー(17)を削除してください。| インディアン座/RspをM削除してください。| なし| | 複数の回答(18)| 繋がっている識別| なし| | 複数のオブジェクト選択(19)| 範囲、フィルタは同期します。 | なし| | 拡張サービス(20)| 拡張プレゼンテーション| なし| +---------------------------------+------------------------+------非確認されたN+ 確認されたC=、U=/は適切でない=です。
Table 2. Functional Units
2を見送ってください。 機能的なユニット
In addition to the stand alone functional units, there are three additional functional units. If any of these additional functional units are selected, then at least one of the stand alone functional units must be selected. The multiple reply functional unit makes available the use of the linked identification parameter in the selected stand alone functional units. This makes possible the use of linked reply (multiple CMIP PDU responses to a single request). The multiple object selection functional unit makes available the use of the scope, filter, and synchronization parameters in the selected stand alone functional units. If the multiple object selection functional unit is selected, then the multiple reply functional unit must also be selected. The extended services functional unit makes available presentation layer services in addition to the P-DATA service. Selecting this functional unit has no effect in the context of CMOT, since the lightweight presentation layer provides only minimal ISO presentation services.
スタンドアロンの機能的なユニットに加えて、追加機能的な3個のユニットがあります。 これらの追加機能的なユニットのどれかが選択されるなら、少なくともスタンドアロンの機能的なユニットの1つを選択しなければなりません。 複数の回答の機能的なユニットで、選択されたスタンドアロン機能的なユニットにおける繋がっている識別パラメタの使用は利用可能になります。 これで、繋がっている回答(ただ一つの要求への複数のCMIP PDU応答)の使用は可能になります。 複数のオブジェクト選択機能的なユニットで、選択されたスタンドアロン機能的なユニットの範囲、フィルタ、および同期パラメタの使用は利用可能になります。 また、複数のオブジェクト選択機能的なユニットが選択されるなら、複数の回答の機能的なユニットを選択しなければなりません。 機能的なユニットがP-DATAサービスに加えた利用可能なプレゼンテーション層サービスをする拡張サービス。 この機能的なユニットを選択するのはCMOTの文脈で効き目がありません、軽量のプレゼンテーション層が最小量のISOプレゼンテーション・サービスだけを提供するので。
Warrier & Besaw [Page 35] RFC 1095 CMOT April 1989
Warrier&Besaw[35ページ]RFC1095CMOT1989年4月
7.1.3. Functional Unit Groups
7.1.3. 機能的なユニットグループ
In order to assist in the reduction of code size and complexity for different types of devices, a number of "functional unit groups" have been defined. Each of these groups indicates a set of services defined for either a manager or an agent. The "negotiation" concerning which functional unit groups are supported is done by means of the Functional Units parameter of the M-INITIALISE service (see section 7.1.4.1). There are five functional unit groups for managers: Event Monitor, Monitoring Manager, Simple Manager, Controlling Manager, and Full Manager. Each functional unit group is a superset of the preceding group. There are five functional unit groups for agents: Event Sender, Monitored Agent, Simple Agent, Controlled Agent, and Full Agent. Again, each functional unit group is a superset of the preceding group. The operations supported for each functional unit group are summarized in Table 3.
異なったタイプのデバイスのためにコードサイズと複雑さの減少を助けるために、「機能的なユニットは分類する」数が定義されました。 それぞれのこれらのグループはマネージャかエージェントのどちらかのために定義された1セットのサービスを示します。 セクション7.1を見てください。M-INITIALISEサービスのFunctional Unitsパラメタによって機能的なユニットグループがサポートされる「交渉」をする、(.4 .1)。 マネージャのための5つの機能的なユニットグループがあります: イベントモニター、モニターしているマネージャ、純真なマネージャ、制御マネージャ、および完全なマネージャ。 それぞれの機能的なユニットグループは前のグループのスーパーセットです。 エージェントのための5つの機能的なユニットグループがあります: イベント送付者(モニターされたエージェント、純真なエージェント)はエージェント、および完全なエージェントを監督しました。 一方、それぞれの機能的なユニットグループは前のグループのスーパーセットです。 それぞれの機能的なユニットグループのためにサポートされた操作はTable3にまとめられます。
+--------------------+------+-----+-----+-------+------+-----+------+
| |Event | Get | Set |Create/|Action|Mult.|Mult. |
|Functional Unit |Report| | |Delete | |Reply|Object|
|Groups | | | | | | |Select|
+--------------------+------+-----+-----+-------+------+-----+------+
| 1. Event Monitor | U | no | no | no | no | no | no |
| 2. Event Sender | U | no | no | no | no | no | no |
| 3. Monitoring Mgr. | U | yes | no | no | no | no | no |
| 4. Monitored Agent | U | yes | no | no | no | no | no |
| 5. Simple Manager | U | yes | C | no | no | yes | no* |
| 6. Simple Agent | U | yes | C | no | no | yes | no* |
| 7. Controlling Mgr.| U | yes | U/C | yes | no | yes | yes |
| 8. Controlled Agent| U | yes | U/C | yes | no | yes | yes |
| 9. Full Manager | U/C | yes | U/C | yes | U/C | yes | yes |
|10. Full Agent | U/C | yes | U/C | yes | U/C | yes | yes |
+--------------------+------+-----+-----+-------+------+-----+------+
C = confirmed, U = non-confirmed
* Simple Managers and Agents must support "oneLevel" scoping for all
and only those cases where it is required to access a whole table
and may support synchronization other than "best effort"; no support
for filtering is required.
+--------------------+------+-----+-----+-------+------+-----+------+ | |イベント| 得てください。| セットします。|/を作成してください。|動作|Mult| Mult。 | |機能的なユニット|レポート| | |削除します。| |返信|オブジェクト| |グループ| | | | | | |選ぶ| +--------------------+------+-----+-----+-------+------+-----+------+ | 1. イベントモニター| U| いいえ| いいえ| いいえ| いいえ| いいえ| いいえ| | 2. イベント送付者| U| いいえ| いいえ| いいえ| いいえ| いいえ| いいえ| | 3. Mgrをモニターします。 | U| はい| いいえ| いいえ| いいえ| いいえ| いいえ| | 4. モニターされたエージェント| U| はい| いいえ| いいえ| いいえ| いいえ| いいえ| | 5. 純真なマネージャ| U| はい| C| いいえ| いいえ| はい| *がありません。| | 6. 純真なエージェント| U| はい| C| いいえ| いいえ| はい| *がありません。| | 7. 制御Mgr| U| はい| U/C| はい| いいえ| はい| はい| | 8. 制御エージェント| U| はい| U/C| はい| いいえ| はい| はい| | 9. 完全なマネージャ| U/C| はい| U/C| はい| U/C| はい| はい| |10. 完全なエージェント| U/C| はい| U/C| はい| U/C| はい| はい| +--------------------+------+-----+-----+-------+------+-----+------+ 確認されたC=、Uが非確認された*純真なマネージャと等しく、エージェントは、それが全体のテーブルにアクセスするのに必要であるそれらのケースだけに関して見ながら"oneLevel"をサポートしなければならなくて、「ベストエフォート型」を除いた同期をサポートするかもしれません。 フィルタリングのサポートは全く必要ではありません。
Table 3. Functional Unit Groups
3を見送ってください。 機能的なユニットグループ
A conformant system must support at least one of these functional unit groups. A system may support both a manager group and an agent group. A system only needs to implement the services and service primitives required for the groups that it supports. In addition, a system may support services that are not required by any group that
conformantシステムは少なくともこれらの機能的なユニットグループの1つをサポートしなければなりません。 システムは、両方がマネージャグループとエージェントグループであるとサポートするかもしれません。 システムは、サービスを実装する必要があるだけです、そして、サービス基関数がそれがサポートするグループに必要です。 さらに、システムはどんなグループによっても必要とされないサービスにそれをサポートするかもしれません。
Warrier & Besaw [Page 36] RFC 1095 CMOT April 1989
Warrier&Besaw[36ページ]RFC1095CMOT1989年4月
it supports.
それはサポートします。
7.1.4. M-INITIALISE Parameters
7.1.4. パラメタをM初期化してください。
The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service. The parameters for the M-INITIALISE service are defined in [11] and summarized in Table 4.
ACSE A-ASSOCIATEサービスでM-INITIALISEサービスを提供します。 M-INITIALISEサービスのためのパラメタは、[11]で定義されて、Table4にまとめられます。
+-------------------+-----------+-----------+
| Parameter Name | Req/Ind | Rsp/Conf |
+-------------------+-----------+-----------+
| Functional Units | Mandatory | Mandatory |
| User Information | Optional | Optional |
| Access Control | Optional | Optional |
+-------------------+-----------+-----------+
+-------------------+-----------+-----------+ | パラメタ名| Req/インディアン座| Rsp/Conf| +-------------------+-----------+-----------+ | 機能的なユニット| 義務的| 義務的| | ユーザー情報| 任意| 任意| | アクセス制御| 任意| 任意| +-------------------+-----------+-----------+
Table 4. M-INITIALISE Parameters
4を見送ってください。 パラメタをM初期化してください。
Notice that the further agreement has been made that the Functional Units parameter is mandatory at all times. The M-INITIALISE parameters are conveyed as ACSE user information in the ACSE request PDU.
Functional Unitsパラメタがいつも義務的であるというさらなる協定をしたのに注意してください。 M-INITIALISEパラメタはACSE要求PDUのACSEユーザー情報として伝えられます。
7.1.4.1. Functional Units
7.1.4.1. 機能的なユニット
The exchange of functional units between the initiating CMISE- service-user and the responding CMISE-service-user is required. This allows the CMIS-service-users to inform each other which functional units are supported. CMIP [12] defines a 21-bit BIT STRING to communicate which functional units are supported. A functional unit is supported if the corresponding bit in this bit string is one. The correspondence between functional units and functional unit groups is given in Table 5. The left column gives the functional unit corresponding to a particular bit position. The numbers along the top of the table indicate the functional unit group (the numbers of the functional unit groups are given in Table 3). The various columns indicate the value of each bit for a particular functional unit group.
開始しているCMISEサービス利用者と応じているCMISE-サービス利用者の間の機能的なユニットの交換が必要です。 これで、CMIS-サービス利用者は、どの機能的なユニットがサポートされるかを互いに知らせることができます。 CMIP[12]は、どの機能的なユニットがサポートされるかを伝えるために21ビットのBIT STRINGを定義します。 機能的なユニットはこのビット列の対応するビットが1であるならサポートされます。 Table5で機能的なユニットと機能的なユニットグループの間の通信を与えます。 左のコラムは特定のビット位置に対応しているのに機能的なユニットを与えます。 テーブルの先端に沿った数は、機能的なユニットが分類されるのを(Table3で機能的なユニットグループの数を与えます)示します。 様々なコラムは特定の機能的なユニットグループのためにそれぞれのビットの価値を示します。
Warrier & Besaw [Page 37] RFC 1095 CMOT April 1989
Warrier&Besaw[37ページ]RFC1095CMOT1989年4月
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|Functional Unit | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10|
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|conf. event report invoker(0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|conf. event report perf.(1) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|event report invoker(2) | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|event report performer(3) | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get invoker(4) | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get performer(5) | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|confirmed set invoker(6) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed set performer(7) | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
|set invoker(8) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|set performer(9) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed action invoker(10) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|confirmed action performer(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|action invoker(12) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|action performer(13) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|confirmed create invoker(14) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed create performer(15)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed delete invoker(16) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed delete performer(17)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|multiple reply(18) | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
|multiple object selection(19) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
|extended service(20) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
| | M | A | M | A | M | A | M | A | M | A |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
1 = supported, 0 = not supported, M = manager, A = agent
+------------------------------+---+---+---+---+---+---+---+---+---+---+ |機能的なユニット| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| +------------------------------+---+---+---+---+---+---+---+---+---+---+ |confイベントレポート呼び出し元(0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |confイベントレポートperf.(1)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |イベントレポート呼び出し元(2)| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | |イベントレポートパフォーマー(3)| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |確認されて、呼び出し元(4)を手に入れてください。| 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |確認されて、パフォーマー(5)を手に入れてください。| 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | |確認されたセット呼び出し元(6)| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |確認されたセットパフォーマー(7)| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | |呼び出し元(8)を設定してください。| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |パフォーマー(9)を設定してください。| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | |確認された動作呼び出し元(10)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |確認された動作パフォーマー(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |動作呼び出し元(12)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |動作パフォーマー(13)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | |確認されて、呼び出し元(14)を創造してください。| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |確認されて、パフォーマー(15)を創造してください。| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | |確認されて、呼び出し元(16)を削除してください。| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |確認されて、パフォーマー(17)を削除してください。| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | |複数の回答(18)| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | |複数のオブジェクト選択(19)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | |拡張サービス(20)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------------------------+---+---+---+---+---+---+---+---+---+---+ | | M| A| M| A| M| A| M| A| M| A| +------------------------------+---+---+---+---+---+---+---+---+---+---+ =がサポートした1、=がサポートしなかった0、M=マネージャ、A=エージェント
Table 5. Functional Unit Group Values
5を見送ってください。 機能的なユニット階級値
The "negotiation" using functional units proceeds as follows. The initiating CMISE-service-user (manager or agent) sends the functional units representing the functional unit group to which it belongs. The responding CMISE-service-user sends the functional units representing the functional unit group to which it belongs. (If an application process belongs to both a manager and an agent functional unit group, then both functional unit groups are indicated using the same functional unit bit string.) If the functional unit groups supported by the two application entities do not allow meaningful communication, then either entity may refuse the association. Meaningful communication is defined as the ability of the entity to invoke or perform at least one CMIS operation supported by the other entity (i.e., some "complementary" set of functional units exists). After an association has been established, a system must provide the proper response for functional units that it has indicated it can support and should gracefully refuse other requests in accordance
機能的なユニットを使用する「交渉」は以下の通り続きます。 開始しているCMISE-サービス利用者(マネージャかエージェント)は機能的なユニットにそれが属する機能的なユニットグループを代表させます。 応じているCMISE-サービス利用者は機能的なユニットにそれが属する機能的なユニットグループを代表させます。 (アプリケーション・プロセスがマネージャとエージェントの機能的なユニットが分類する両方に属すなら、両方の機能的なユニットグループは同じ機能的なユニットビット列を使用することで示されます。) グループが2つのアプリケーション実体でサポートした機能的なユニットが重要なコミュニケーションを許容しないなら、どちらの実体も協会を拒否するかもしれません。 重要なコミュニケーションは実体がもう片方の実体で後押しされている少なくとも1つのCMIS操作を呼び出すか、または実行する能力と定義されます(すなわち何らかの「補足的な」セットの機能的な単位は存在しています)。 協会が設立された後に、システムは、それがサポートすることができるのを示した機能的なユニットのための適切な応答を提供しなければならなくて、優雅に一致における他の要求を拒否するはずです。
Warrier & Besaw [Page 38] RFC 1095 CMOT April 1989
Warrier&Besaw[38ページ]RFC1095CMOT1989年4月
with the protocol.
プロトコルで。
7.1.4.2. User Information
7.1.4.2. ユーザー情報
The User Information parameter is optional. No entity is required to send this parameter, but all entities are expected to tolerate receipt of it.
User情報パラメタは任意です。 実体は全くこのパラメタを送るのに必要ではありませんが、すべての実体がそれの領収書を許容すると予想されます。
One possible use of the User Information parameter is to convey information describing MIB extensions supported by the manager or agent. This can be viewed as a further way of refining the application context. The mechanism for doing this is not defined at this time.
User情報パラメタの1つの活用可能性はマネージャかエージェントによってサポートされたMIB拡張子について説明する情報を伝えることです。 アプリケーション文脈を洗練するさらなる方法としてこれを見なすことができます。 これをするためのメカニズムはこのとき、定義されません。
7.1.4.3. Access Control
7.1.4.3. アクセス制御
The CMIS M-INITIALISE Access Control parameter is optional. Access control is supported on a per association basis using ACSE. It is recommended (but not required) that the access control parameter be used for each A-ASSOCIATE request (via M-INITIALISE).
CMIS M-INITIALISE Access Controlパラメタは任意です。 アクセスコントロールは、協会基礎あたりのaでACSEを使用することでサポートされます。 アクセス管理パラメータがそれぞれのA-ASSOCIATE要求(M-INITIALISEを通した)に使用されることが勧められます(しかし、必要ではありません)。
Access control is also possible on a per request basis with the CMIS Access Control parameter. This parameter might be used to implement security similar to the community access rights mechanism provided by SNMP [4]. It is expected that the Access Control parameter will be used to implement the standard TCP/IP authentication mechanism once this has been defined.
また、アクセスコントロールも要求基礎あたりのaでCMIS Access Controlパラメタで可能です。 このパラメタは、SNMP[4]によって提供された共同体アクセス権メカニズムと同様のセキュリティを実装するのに使用されるかもしれません。 Access Controlパラメタがこれがいったん定義されたあとに標準のTCP/IP認証機構を実装するのに使用されると予想されます。
7.2. Supporting Services
7.2. サービスをサポートします。
The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of ACSE. The following ACSE services are required: A-ASSOCIATE, A- RELEASE, A-ABORT, and A-P-ABORT. The rest of the CMIP protocol uses the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.
M-INITIALISE、M-TERMINATE、およびM-ABORTサービスはACSEの使用を仮定します。 以下のACSEサービスが必要です: A-仲間、Aリリース、A-アボート、およびPアボート。 CMIPプロトコルの残りはローズのRO-INVOKE、RO-RESULT、RO-ERROR、およびRO-REJECTサービスを利用します。
7.3. CMIP Agreements
7.3. CMIP協定
The following sections contain specific CMIP agreements in addition to those specified in the CMIP standard [12].
以下のセクションはCMIP規格[12]で指定されたものに加えて特定のCMIP協定を含みます。
7.3.1. Invoke Identifier
7.3.1. 識別子を呼び出してください。
It is required that there be a unique invoke identifier (present in the ROSE PDU) for successive invocations on the same association. The invoke identifier is provided by the invoking CMISE-service-user. Invoke identifiers should increase monotonically during the lifetime of an association. Semantically, the invoke identifier is a Counter as defined in [2]. Unique identifiers will allow the detection of
それが必要である、それ、そこ、aがユニークであったなら、連続した実施のために、同じ協会に識別子(ROSE PDUで現在の)を呼び出してください。 識別子を呼び出してください。呼び出しているCMISE-サービス利用者によって提供されます。 識別子を呼び出してください。協会の生涯単調に増強するべきです。 意味的に、呼び出し、識別子は[2]で定義されるようにCounterです。 意志が検出を許すユニークな識別子
Warrier & Besaw [Page 39] RFC 1095 CMOT April 1989
Warrier&Besaw[39ページ]RFC1095CMOT1989年4月
lost and duplicate requests.
要求を失って、コピーしてください。
7.3.2. Object Class
7.3.2. オブジェクトのクラス
The object class field of all CMIP PDUs shall be limited to the "globalForm" choice:
すべてのCMIP PDUsのオブジェクト類体は"globalForm"選択に制限されるものとします:
ObjectClass ::=
CHOICE {
globalForm [0] IMPLICIT OBJECT IDENTIFIER
}
ObjectClass:、:= 選択globalForm[0]潜在目的語識別子
7.3.3. Object Instance
7.3.3. オブジェクトインスタンス
The object instance field of all CMIP PDUs is limited to the "distinguishedName" choice:
すべてのCMIP PDUsのオブジェクトインスタンス分野は"distinguishedName"選択に制限されます:
ObjectInstance ::=
CHOICE {
distinguishedName [2] IMPLICIT DistinguishedName
}
ObjectInstance:、:= 選択distinguishedName[2]の内在しているDistinguishedName
The definition for DistinguishedName is imported from CCITT X.500 and ISO DIS 9594-2 [26]:
DistinguishedNameのための定義はCCITT X.500とISO DIS9594-2[26]からインポートされます:
DistinguishedName ::= RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeValueAssertion
DistinguishedName:、:= RDNSequence RDNSequence:、:= RelativeDistinguishedName RelativeDistinguishedNameの系列:、:= AttributeValueAssertionのセット
The definition for AttributeValueAssertion is contained in CMIP [12]:
AttributeValueAssertionのための定義はCMIP[12]に含まれています:
AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue }
AttributeId ::=
CHOICE {
globalId [0] IMPLICIT OBJECT IDENTIFIER
localId [1] IMPLICIT INTEGER
}
AttributeValue ::= ANY DEFINED BY attributeId
AttributeValueAssertion:、:= AttributeId、AttributeValueを配列してください、AttributeId:、:= 選択globalId[0]潜在目的語の識別子のlocalIdの[1]の暗黙の整数AttributeValue:、:= 何でもattributeIdによって定義されます。
Those attributes to be used as the distinguished attributes of a managed object are defined at the time of registration of the object class and are identified in the NAMES clause of the OBJECT-CLASS macro.
それらの管理オブジェクトの顕著な属性として使用されるべき属性は、オブジェクトのクラスの登録時点で、定義されて、OBJECT-CLASSマクロのNAMES節で特定されます。
Warrier & Besaw [Page 40] RFC 1095 CMOT April 1989
Warrier&Besaw[40ページ]RFC1095CMOT1989年4月
When there is no instance information to convey about a managed object, then the following "empty" object instance shall be used: The "distinguishedName" choice of ObjectInstance shall be an RDNSequence consisting of a SEQUENCE of one RelativeDistinguishedName. That RelativeDistinguishedName shall be an empty SET of AttributeValueAssertions.
管理オブジェクトに関して伝えるインスタンス情報が全くないと、以下の「空」のオブジェクトインスタンスは使用されるものとします: ObjectInstanceの"distinguishedName"選択は1RelativeDistinguishedNameのSEQUENCEから成るRDNSequenceになるでしょう。 そのRelativeDistinguishedNameはAttributeValueAssertionsの空のSETになるでしょう。
7.3.4. Access Control
7.3.4. アクセス制御
The access control parameter is optional. The receipt of this parameter must be tolerated (i.e., gracefully accepted), but a receiving entity is free to ignore this information. The Access Control field is defined in [12] as EXTERNAL. Until a more sophisticated access control mechanism is defined, simple authentication can be accomplished by using an unencrypted password in the access control field. The definition of this EXTERNAL is the same as that for the ACSE Access Control field (section 8.3.2).
アクセス管理パラメータは任意です。 このパラメタの領収書を許容しなければなりませんが(すなわち、優雅に、受け入れます)、受信実体は自由にこの情報を無視できます。 Access Control分野は[12]でEXTERNALと定義されます。 より精巧なアクセス管理機構が定義されるまで、アクセス制御フィールドで非暗号化されたパスワードを使用することによって、簡易認証を実行できます。 このEXTERNALの定義はACSE Access Control分野(セクション8.3.2)へのそれと同じです。
7.3.5. Synchronization
7.3.5. 同期
Support for "best effort" synchronization is required. Atomic synchronization may also be supported, but is not required.
「ベストエフォート型」の同期のサポートが必要です。 原子同期は、また、サポートされるかもしれませんが、必要ではありません。
7.3.6. Scope
7.3.6. 範囲
Scoping is supported if the multiple object selection functional unit is selected. If scoping is supported, all values of the scope field shall be supported.
複数のオブジェクト選択機能的なユニットが選択されるなら、見ることはサポートされます。 見るのがサポートされて、範囲分野のすべての値がサポートされるものとするということであるなら。
7.3.7. Filter
7.3.7. フィルタ
Filtering is supported if the multiple object selection functional
unit is selected. If filtering is supported, it is not required that
all features of filtering be supported. The following are the
minimal filtering requirements for any system that supports
filtering. In the CMIP field CMISFilter, at least two instances of
the binary operators ("and," "or") must be supported. Support for
additional instances of these operators is not required. Double
"not" need not be supported. In FilterItem, the arithmetic
operations ("equality", "greaterOrEqual," "lessOrEqual") must be
supported. The "present" choice of FilterItem must also be
supported. It is not required to support string operations (namely,
the "substrings" choice of the FilterItem type). Thus, the minimal
requirements for filtering yield this restricted definition of
FilterItem:
複数のオブジェクト選択機能的なユニットが選択されるなら、フィルタリングはサポートされます。 フィルタリングがサポートされるなら、フィルタリングのすべての特徴がサポートされるのが必要ではありません。 ↓これはフィルタリングをサポートするどんなシステムのための最小量のフィルタリング要件です。 そして、CMIPでは、CMISFilter、2項演算子の少なくとも2つのインスタンスをさばいてください、(「」、“or") サポートしなければなりません。 これらのオペレータの追加インスタンスのサポートは必要ではありません。 二重“not"はサポートされる必要はありません。 FilterItemでは、四則演算(「平等」、"greaterOrEqual""lessOrEqual")をサポートしなければなりません。 また、FilterItemの「現在」の選択をサポートしなければなりません。 それは、ストリング操作が(すなわち、FilterItemタイプの「サブストリング」選択)であるとサポートするのに必要ではありません。 したがって、フィルタリングのための最小量の要件はFilterItemのこの制限された定義をもたらします:
Warrier & Besaw [Page 41] RFC 1095 CMOT April 1989
Warrier&Besaw[41ページ]RFC1095CMOT1989年4月
FilterItem ::=
CHOICE {
equality [0] AttributeValueAssertion,
greaterOrEqual [2] AttributeValueAssertion,
lessOrEqual [3] AttributeValueAssertion,
present [4] AttributeID
}
FilterItem:、:= 選択平等[0]AttributeValueAssertion(greaterOrEqual[2]AttributeValueAssertion、lessOrEqual[3]AttributeValueAssertion)は[4] AttributeIDを寄贈します。
7.3.8. Attribute Identifier
7.3.8. 属性識別子
Both choices for the CMIP AttributeId field are allowed:
CMIP AttributeId分野のための両方の選択は許されています:
AttributeId ::=
CHOICE {
globalId [0] IMPLICIT OBJECT IDENTIFIER,
localId [1] IMPLICIT INTEGER
}
AttributeId:、:= 選択globalId[0]潜在目的語識別子、localIdの[1]の暗黙の整数
The "globalId" form of AttributeId is required if scoping is used (i.e., the value of the scope field is other than "baseObject").
見るのが使用されているなら("baseObject"を除いて、すなわち、範囲分野の値があります)、"globalId"というAttributeIdのフォームが必要です。
7.3.9. Event Type Identifier
7.3.9. イベントタイプ識別子
Both choices for the CMIP EventTypeId field are allowed:
CMIP EventTypeId分野のための両方の選択は許されています:
EventTypeId ::=
CHOICE {
globalId [6] IMPLICIT OBJECT IDENTIFIER,
localId [7] IMPLICIT INTEGER
}
EventTypeId:、:= 選択globalId[6]潜在目的語識別子、localIdの[7]の暗黙の整数
7.3.10. Action Type Identifier
7.3.10. 動作タイプ識別子
Both choices for the CMIP ActionTypeId field are allowed:
CMIP ActionTypeId分野のための両方の選択は許されています:
ActionTypeId ::=
CHOICE {
globalId [2] IMPLICIT OBJECT IDENTIFIER,
localId [3] IMPLICIT INTEGER
}
ActionTypeId:、:= 選択globalId[2]潜在目的語識別子、localIdの[3]の暗黙の整数
Warrier & Besaw [Page 42] RFC 1095 CMOT April 1989
Warrier&Besaw[42ページ]RFC1095CMOT1989年4月
The "globalId" form of ActionTypeId is required if scoping is used (i.e., the value of the scope field is other than "baseObject").
見るのが使用されているなら("baseObject"を除いて、すなわち、範囲分野の値があります)、"globalId"というActionTypeIdのフォームが必要です。
7.3.11. Time Fields
7.3.11. 時間分野
The "eventTime" field of the m-EventReport Invoke PDU and the m- EventConfirmedReport Invoke PDU must be present.
m-EventReport Invoke PDUとm EventConfirmedReport Invoke PDUの"eventTime"分野は存在していなければなりません。
The "currentTime" field of the following PDUs must be present: the m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete Result PDU, the GetListError Error PDU, and the SetListError Error PDU.
以下のPDUsの"currentTime"分野は存在していなければなりません: m-EventReportの確認された結果PDU、m得ている結果PDU、mに設定された結果PDU、m動作が結果PDUを確認した、結果PDUをm作成してください、結果PDU、GetListError誤りPDU、およびSetListError誤りPDUをm削除してください。
All CMIP time fields shall use the ASN.1 GeneralizedTime type defined in [5] with 1 millisecond granularity.
すべてのCMIP時間分野が1ミリセカンドの粒状で[5]で定義されたASN.1GeneralizedTimeタイプを使用するものとします。
If the system generating the PDU does not have the current time, yet does have the time since last boot, then GeneralizedTime can be used to encode this information. The time since last boot will be added to the base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar algorithm. (In the Gregorian calendar, all years have 365 days except those divisible by 4 and not by 400, which have 366.) The use of the year 1 as the base year will prevent any confusion with current time.
PDUを生成するシステムが現在の時間を過しませんが、最後のブーツ以来の時間を持っているなら、この情報をコード化するのにGeneralizedTimeを使用できます。 最後のブーツ以来の時間はベース時間「グレゴリオ暦アルゴリズムを使用する201年1月1日の00:00:0インチ」に加えられるでしょう。 (グレゴリオ暦では、400で分割可能であるのではなく、4で分割可能なものを除いて、すべての年が365日間を持っています。)(ものは366を持っています)。 基準年としての1がそうする1年の使用は現在の時間へのどんな混乱も防ぎます。
If no meaningful time is available, then the year 0 shall be used in GeneralizedTime to indicate this fact.
どんな重要な時間も空かないなら0がそうする年にGeneralizedTimeで使用されて、この事実を示してください。
7.3.12. Response PDUs
7.3.12. 応答PDUs
Both the "managedObjectClass" and "managedObjectInstance" fields must be present in the following CMIP response PDUs: the m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete Result PDU, the GetListError Error PDU, and the SetListError Error PDU. The "managedObjectInstance" field must be present in the ProcessingFailure Error PDU. The "managedObjectClass" field must be present in the NoSuchArgument Error PDU.
両方の「managedObjectClass」と"managedObjectInstance"分野は以下のCMIP応答PDUsで存在していなければなりません: m-EventReportの確認された結果PDU、m得ている結果PDU、mに設定された結果PDU、m動作が結果PDUを確認した、結果PDUをm作成してください、結果PDU、GetListError誤りPDU、およびSetListError誤りPDUをm削除してください。 "managedObjectInstance"分野はProcessingFailure Error PDUに存在していなければなりません。 「managedObjectClass」分野はNoSuchArgument Error PDUに存在していなければなりません。
7.3.13. Error PDUs
7.3.13. 誤りPDUs
The "globalId" form of AttributeId is required for the NoSuchAttributeId Error PDU and the InvalidAttributeValue Error PDU.
"globalId"というAttributeIdのフォームがNoSuchAttributeId Error PDUとInvalidAttributeValue Error PDUに必要です。
8. Association Control Service Element
8. アソシエーション制御サービス要素
The Association Control Service Element (ACSE), which is necessary
アソシエーション制御サービス要素(ACSE)。(そのアソシエーション制御サービス要素が、必要です)。
Warrier & Besaw [Page 43] RFC 1095 CMOT April 1989
Warrier&Besaw[43ページ]RFC1095CMOT1989年4月
for establishing and releasing application associations, is defined in [7] and [8].
応用アソシエーションを設立して、リリースするために、定義されたコネは、[7]と[8]ですか?
8.1. ACSE Services
8.1. ACSEサービス
The ACSE service description is detailed in ISO 8649 [7]. All of the defined ACSE services are mandatory:
ACSEサービス記述はISO8649[7]で詳細です。 定義されたACSEサービスのすべてが義務的です:
o A-ASSOCIATE: This confirmed service is used to initiate an
application association between application entities.
o 1仲間: これは、サービスがアプリケーション実体の間の応用アソシエーションを開始するのに利用されると確認しました。
o A-RELEASE: This confirmed service is used to release an
application association between application entities without
loss of information.
o 1リリース: これは、サービスが情報の損失なしでアプリケーション実体の間の応用アソシエーションをリリースするのに利用されると確認しました。
o A-ABORT: This unconfirmed service causes the abnormal release
of an association with a possible loss of information.
o 1アボート: この未確認のサービスは情報の可能な損失との協会の異常なリリースを引き起こします。
o A-P-ABORT: This provider-initiated service indicates the
abnormal release of an application association by the
underlying presentation service with a possible loss of
information.
o Pアボート: このプロバイダーで開始しているサービスは情報の可能な損失で基本的なプレゼンテーション・サービスによる応用アソシエーションの異常なリリースを示します。
Mappings of the ACSE services to presentation services and ACSE APDUs are shown in Table 6, along with a section reference to ISO 8649 [7].
プレゼンテーション・サービスとACSE APDUsに対するACSEサービスのマッピングはTable6に示されます、ISO8649[7]のセクション参照と共に。
+-------------+------------+----------------------+-------------+
| ACSE | ISO 8649 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| A-ASSOCIATE | 9.1 | P-CONNECT | AARQ, AARE |
| A-RELEASE | 9.2 | P-RELEASE | RLRQ, RLRE |
| A-ABORT | 9.3 | P-U-ABORT | ABRT |
| A-P-ABORT | 9.4 | P-P-ABORT | (none) |
+-------------+------------+----------------------+-------------+
+-------------+------------+----------------------+-------------+ | ACSE| ISO8649| 関係します。| 交際します。| | サービス| 参照| プレゼンテーション・サービス| APDUs| +-------------+------------+----------------------+-------------+ | 1交際します。| 9.1 | Pで接続してください。| AARQ、アーレ| | 1リリースします。| 9.2 | P-リリース| RLRQ、RLRE| | 1アボートします。| 9.3 | P-U-アボート| ABRT| | Pアボート| 9.4 | P-P-アボート| (なにも) | +-------------+------------+----------------------+-------------+
Table 6. Mapping of ACSE Services
6を見送ってください。 ACSEサービスのマッピング
8.2. Supporting Services
8.2. サービスをサポートします。
ACSE will make use of the following ISO presentation layer services: P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT. These presentation services will be provided by the LPP [13].
ACSEは以下のISOプレゼンテーション層サービスを利用するでしょう: Pで接続して、Pでリリースして、P-U中止になって、P-P中止になります。 これらのプレゼンテーション・サービスはLPP[13]によって提供されるでしょう。
Warrier & Besaw [Page 44] RFC 1095 CMOT April 1989
Warrier&Besaw[44ページ]RFC1095CMOT1989年4月
8.3. ACSE Protocol
8.3. ACSEプロトコル
The ACSE protocol specification is found in ISO 8650 [8]. All five ACSE APDUs specified in the standard are mandatory.
ACSEプロトコル仕様はISO8650[8]で見つけられます。 規格で指定されたすべての5ACSE APDUsが義務的です。
8.3.1. Application Context Name
8.3.1. アプリケーション文脈名
The Application Context Name takes the form of an OBJECT IDENTIFIER.
The value of this OBJECT IDENTIFIER includes both the version of CMOT
being used for this association and the version number of the highest
version of the Internet-standard MIB supported by the manager or
agent. The application context name has the following generic form:
Application Context NameはOBJECT IDENTIFIERの形を取ります。 このOBJECT IDENTIFIERの値はマネージャかエージェントによってサポートされたこの協会に使用されるCMOTのバージョンとインターネット標準MIBの最も高いバージョンのバージョン番号の両方を含んでいます。 アプリケーション文脈名で、以下のジェネリックは形成されます:
{ iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
cmot(9) cmotVersion(1) version-number(v) }
iso(1) org(3) dod(6)インターネット(1)管理(2)mib(n) cmot(9) cmotVersion(1)バージョン番号(v)
where n = highest MIB version supported and
v = version of CMOT supported
nがサポートされて、CMOTの=バージョンに対してサポートされる中で最も高いMIBバージョンと等しいところ
For the version of CMOT defined in these agreements, "version-number" has the value of one (1). This version of CMOT implies the versions of the ISO protocols specified in this memo (see Figure 2).
これらの合意で定義されたCMOTのバージョンのために、「バージョン番号」には、1つ(1)の値があります。 CMOTのこのバージョンは、ISOプロトコルのバージョンがこのメモで指定したのを(図2を見てください)含意します。
8.3.2. User Information
8.3.2. ユーザー情報
The following CMIS M-INITIALISE parameters are all mapped onto the ACSE User Information parameter: Functional Units, User Information, and Access Control. (See section 7.1.4 for more information on the CMIS M-INITIALISE parameters.) ACSE User Information is defined in ISO 8650 as follows:
以下のCMIS M-INITIALISEパラメタはACSE User情報パラメタにすべて写像されます: 機能的なユニット、ユーザー情報、およびアクセスは制御されます。 (CMIS M-INITIALISEパラメタの詳しい情報に関してセクション7.1.4を見てください。) ACSE User情報は以下のISO8650で定義されます:
Association-information ::= SEQUENCE OF EXTERNAL
協会情報:、:= 外部の系列
The ASN.1 defined type EXTERNAL, which is defined in section 35 of ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification and an associated ASN.1 encoding.
ASN.1の定義されたタイプEXTERNAL(ISO8824[5]のセクション35で定義される)は識別のためのOBJECT IDENTIFIERと関連ASN.1コード化の両方を必要とします。
The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
acse(0) functional-units(0) } and the syntax is a BIT STRING.
ACSE Functional Units EXTERNAL定義に関連しているOBJECT IDENTIFIERと構文は[12]で見つけられます。 OBJECT IDENTIFIERは標準のiso(1)の(0)ips-osi-mips(9596)cmip(2)バージョン(1)acse(0)機能的なユニット(0)と定義されます、そして、構文はBIT STRINGです。
The EXTERNAL definition for User Information is left unspecified at this time; it will be defined in a future memo.
User情報のためのEXTERNAL定義はこのとき、不特定のままにされます。 それは将来のメモで定義されるでしょう。
If some form of access control is required, a simple unencrypted
何らかの形式のアクセスコントロールが非暗号化されていた状態で必要であって、a簡単であるなら
Warrier & Besaw [Page 45] RFC 1095 CMOT April 1989
Warrier&Besaw[45ページ]RFC1095CMOT1989年4月
password can be used. The EXTERNAL for this simple access control
will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
and the syntax OCTET STRING. A more sophisticated authentication
mechanism will be defined with another EXTERNAL definition in a
future memo.
パスワードを使用できます。 この簡単なアクセス制御のためのEXTERNALはOBJECT IDENTIFIER cmotAcseAccessControl(付録A)と構文OCTET STRINGを使用するでしょう。 より精巧な認証機構は将来のメモとの別のEXTERNAL定義で定義されるでしょう。
8.3.3. Presentation Service Parameters
8.3.3. プレゼンテーション・サービスパラメタ
The values and defaults of parameters to the ACSE primitives that are given to the presentation service are specified in RFC 1085 [13].
プレゼンテーション・サービスに与えられているACSE基関数へのパラメタの値とデフォルトはRFC1085[13]で指定されます。
For the Presentation Context Definition List parameter to the P- CONNECT service [13, p. 10], the value of the Abstract Syntax Name associated with the Presentation Context Identifier of value one (1) shall be identical to the OBJECT IDENTIFIER used for the Application Context Name (section 8.3.1).
P CONNECTサービスへのPresentation Context Definition Listパラメタのために[13 p。 10], 抽象的なSyntax Nameの値は1(1)がそうする価値のPresentation Context Identifierと交際しました。Application Context Name(セクション8.3.1)に使用されるOBJECT IDENTIFIERと同じにしてください。
The Quality of Service parameter shall have the value of either "tcp-based" or "udp-based."
ServiceパラメタのQualityは「tcpベース」か「udpベース」にどちらかの値を持っているものとします。
9. Remote Operations Service Element
9. リモート操作は要素を調整します。
The Remote Operations Service Element (ROSE), which provides the ability to invoke remote operations, is specified in ISO 9072-1 [9] and 9072-2 [10]. ROSE can only be used once an association has been established between two application entities. ROSE is used to support CMISE; it is not intended to be used directly by management application processes.
Remote Operations Service Element(ローズ)はISO9072-1[9]と9072-2[10]で指定されます。(Remote Operations Service Elementはリモート操作を呼び出す能力を提供します)。 協会が2つのアプリケーション実体の間にいったん設立されると、ローズを使用できるだけです。 ローズはCMISEをサポートするのに使用されます。 直接管理アプリケーション・プロセスでそれが使用されることを意図しません。
9.1. ROSE Services
9.1. バラサービス
The ROSE service definition is detailed in ISO 9072-1 [9]. All of the defined ROSE services are mandatory:
ローズのサービス定義はISO9072-1[9]で詳細です。 定義されたローズのサービスのすべてが義務的です:
o RO-INVOKE: This unconfirmed service is used by an invoking
ROSE-user to cause the invocation of an operation to be
performed by an invoked ROSE-user.
o 以下をRO呼び出してください。 この未確認のサービスは、操作の実施が呼び出されたローズ-ユーザによって実行されることを引き起こすのに呼び出しているローズ-ユーザによって利用されます。
o RO-RESULT: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of a successfully performed operation.
o RO-結果: この未確認のサービスは、首尾よく実行された操作の場合で前のRO-INVOKE指示に答えるのに呼び出されたローズ-ユーザによって利用されます。
o RO-ERROR: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of an unsuccessfully performed operation.
o RO-誤り: この未確認のサービスは、実行された失敗した操作の場合で前のRO-INVOKE指示に答えるのに呼び出されたローズ-ユーザによって利用されます。
o RO-REJECT-U: This unconfirmed service is used by a ROSE-user
to reject a request (RO-INVOKE indication) of the other
o ROはUを拒絶します: この未確認のサービスは、もう片方の要求(RO-INVOKE指示)を拒絶するのにローズ-ユーザによって利用されます。
Warrier & Besaw [Page 46] RFC 1095 CMOT April 1989
Warrier&Besaw[46ページ]RFC1095CMOT1989年4月
ROSE-user if it has detected a problem. It may also be used
by a ROSE-user to (optionally) reject a reply (RO-RESULT
indication, RO-ERROR indication) from the other ROSE-user.
ローズ-ユーザはそれであるなら問題を検出しました。 また、それは、もう片方のローズ-ユーザから回答(RO-RESULT指示、RO-ERROR指示)を(任意に、)拒絶するのにローズ-ユーザによって使用されるかもしれません。
o RO-REJECT-P: This provider-initiated service is used to advise
a ROSE-user of a problem detected by the ROSE-provider.
o ROはPを拒絶します: このプロバイダーで開始しているサービスは、ローズ-プロバイダーによって検出された問題をローズ-ユーザに知らせるのに利用されます。
Mappings of ROSE services to ISO presentation services and ROSE APDUs are shown in Table 7, along with a section reference to ISO 9072-1 [9].
ISOプレゼンテーション・サービスとローズAPDUsに対するローズのサービスのマッピングはTable7に示されます、ISO9072-1[9]のセクション参照と共に。
+-------------+------------+----------------------+-------------+
| ROSE | ISO 9072-1 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| RO-INVOKE | 10.1 | P-DATA | ROIV |
| RO-RESULT | 10.2 | P-DATA | RORS |
| RO-ERROR | 10.3 | P-DATA | ROER |
| RO-REJECT-U | 10.4 | P-DATA | RORJ |
| RO-REJECT-P | 10.5 | P-DATA | RORJ |
+-------------+------------+----------------------+-------------+
+-------------+------------+----------------------+-------------+ | 上昇しました。| ISO9072-1| 関係します。| 交際します。| | サービス| 参照| プレゼンテーション・サービス| APDUs| +-------------+------------+----------------------+-------------+ | RO呼び出します。| 10.1 | P-データ| ROIV| | RO-結果| 10.2 | P-データ| RORS| | RO-誤り| 10.3 | P-データ| ROER| | ROはUを拒絶します。| 10.4 | P-データ| RORJ| | ROはPを拒絶します。| 10.5 | P-データ| RORJ| +-------------+------------+----------------------+-------------+
Table 7. Mapping of ROSE Services
7を見送ってください。 バラサービスのマッピング
9.2. Supporting Services
9.2. サービスをサポートします。
ROSE will only make use of the presentation layer service P-DATA. This service is provided by the LPP. The following restrictions are a consequence of the use of the LPP: First, mappings to the Reliable Transfer Service Element (RTSE) are not possible, since no RTSE is present. Second, no data token is used with the presentation services.
ローズはプレゼンテーション層サービスP-DATAを利用するだけでしょう。 このサービスはLPPによって提供されます。 以下の制限はLPPの使用の結果です: どんなRTSEも存在していないので、まず最初に、Reliable Transfer Service Element(RTSE)へのマッピングは可能ではありません。 2番目に、データトークンは全くプレゼンテーション・サービスと共に使用されません。
9.3. ROSE Protocol
9.3. バラプロトコル
The protocol specification for ROSE shall follow ISO 9072-2 [10]. All four APDUs specified in the standard are mandatory. In addition, the ability to support the correct origination and reception of the linked-id protocol element is required if the multiple reply functional unit has been selected (section 7.1.2).
ローズへのプロトコル仕様はISO9072-2[10]に続くものとします。 規格で指定されたすべての4APDUsが義務的です。 さらに、繋がっているイドプロトコル要素の正しい創作とレセプションをサポートする能力は複数の回答であるなら必要であることで、機能的なユニットが選択されたという(セクション7.1.2)ことです。
9.3.1. Operation Class
9.3.1. 操作のクラス
Since no turn management is required by ROSE, the Operation Class parameter may be ignored.
回転管理が全くローズによって必要とされないので、Operation Classパラメタは無視されるかもしれません。
Warrier & Besaw [Page 47] RFC 1095 CMOT April 1989
Warrier&Besaw[47ページ]RFC1095CMOT1989年4月
9.3.2. Priority
9.3.2. 優先権
ROSE will deliver each APDU in a "first in, first out" manner. Since no turn management is required by ROSE, the Priority parameter may be ignored.
ローズは「中と最初に、最初に、出かけている」方法で各APDUを提供するでしょう。 回転管理が全くローズによって必要とされないので、Priorityパラメタは無視されるかもしれません。
10. Lightweight Presentation
10. 軽量のプレゼンテーション
The specification for the lightweight presentation protocol (LPP) is contained in RFC 1085, "ISO Presentation Services on top of TCP/IP- based internets" [13]. The services defined in that memo are the minimal set of ISO presentation services required to support ACSE and ROSE. The protocol specified to provide these services is a replacement for the ISO presentation protocol.
軽量のプレゼンテーションプロトコル(LPP)のための仕様はRFC1085(「TCP/IPベースのインターネットの上のISO Presentation Services」[13])に含まれています。 そのメモで定義されたサービスはプレゼンテーション・サービスがACSEとローズをサポートするのを必要としたISOの極小集合です。 これらのサービスを提供するために指定されたプロトコルはISOプレゼンテーションプロトコルへの交換です。
10.1. Lightweight Presentation Services
10.1. 軽量のプレゼンテーション・サービス
All of the ISO presentation services provided by the LPP are mandatory: P-CONNECT, P-RELEASE, P-U-ABORT, P-P-ABORT, and P-DATA.
LPPによって提供されたISOプレゼンテーション・サービスのすべてが義務的です: Pで接続してください、P-リリース、P-U-アボート、P-P-アボート、およびP-データ。
10.2. Supporting Services
10.2. サービスをサポートします。
Depending on the quality of service indicated in the P-CONNECT request, the LPP will use either UDP (low quality) or TCP (high quality) as the underlying transport protocol. UDP provides an unreliable datagram service, while TCP provides a reliable connection-oriented transport service.
P-CONNECT要求で示されたサービスの質によって、LPPは基本的なトランスポート・プロトコルとしてUDP(低品質)かTCP(高品質の)のどちらかを使用するでしょう。 UDPは頼り無いデータグラムサービスを提供しますが、TCPは信頼できる接続指向の輸送サービスを提供します。
Practically speaking, there are two ways to discover whether a remote system supports the LPP over UDP or TCP. The first is to use some undefined form of directory service. This might be nothing more than a local table. The second way is simply to attempt to establish an association with the remote application entity using the desired quality of service. If the transport for that service is unavailable on the remote system, then the local presentation-service-provided will issue a negative P-CONNECT.CONFIRMATION primitive. This will be interpreted by ACSE as a failure to establish an association with the desired quality of service.
実際に話すなら、リモートシステムがUDPかTCPの上でLPPをサポートするかどうか発見する2つの方法があります。 1番目は何らかの未定義のフォームのディレクトリサービスを使用することです。 これはただ地方のテーブルであるかもしれません。 2番目の道は必要なサービスの質を使用するリモートアプリケーション実体との協会を設立するのを単に試みることです。 そのサービスのための輸送がリモートシステムの上で入手できないなら、サービスが提供した地方のプレゼンテーションは原始的に否定的P-CONNECT.CONFIRMATIONを発行するでしょう。 これは必要なサービスの質との協会を設立しないこととしてACSEによって解釈されるでしょう。
The following well-known UDP and TCP port numbers are defined:
以下のよく知られるUDPとTCPポートナンバーは定義されます:
cmot manager 163/tcp
cmot manager 163/udp
cmot agent 164/tcp
cmot agent 164/udp
cmotマネージャの163/tcp cmotマネージャの163/udp cmotエージェントの164/tcp cmotエージェント164/udp
When UDP is used, an implementation need not accept a lightweight presentation PDU whose length exceeds 484. The purpose of this
UDPが使用されているとき、実装はライト級のために、長さが484を超えているプレゼンテーションPDUを受け入れる必要はありません。 この目的
Warrier & Besaw [Page 48] RFC 1095 CMOT April 1989
Warrier&Besaw[48ページ]RFC1095CMOT1989年4月
restriction is to ensure that CMIP requests and responses can be transmitted in a single unfragmented IP datagram.
制限は単一の非断片化しているIPデータグラムでCMIP要求と応答を伝えることができるのを保証することです。
10.3. Lightweight Presentation Protocol
10.3. 軽量のプレゼンテーションプロトコル
No further agreements are needed for the lightweight presentation protocol defined in RFC 1085.
さらなる協定は全くRFC1085で定義された軽量のプレゼンテーションプロトコルに必要ではありません。
11. Acknowledgements
11. 承認
This RFC is the work of many people. The following members of the IETF Netman working group and other interested individuals made important contributions:
このRFCは多くの人々の仕事です。 IETF Netmanワーキンググループと他の関心がある個人の以下のメンバーは重要な貢献をしました:
Amatzia Ben-Artzi, 3Com
Asheem Chandna, AT&T Bell Laboratories
Ken Chapman, Digital Equipment Corporation
Anthony Chung, Sytek
George Cohn, Ungermann-Bass
Gabriele Cressman, Sun Microsystems
Pranati Kapadia, Hewlett-Packard
Lee LaBarre, The MITRE Corporation (chair)
Dave Mackie, 3Com
Keith McCloghrie, The Wollongong Group
Jim Robertson, 3Com
Milt Roselinsky, CMC
Marshall Rose, The Wollongong Group
John Scott, Data General
Lou Steinberg, IBM
Amatziaベン-Artzi、3Com Asheem Chandna、AT&Tベル研究所のケン・チャップマン、DECのアンソニー・チャン、Sytekジョージ・コーン、アンガマン-バスガブリエレCressman、サン・マイクロシステムズのPranatiカパディア、ヒューレット・パッカードリーLaBarre、斜め継ぎ社(いす)のデーヴMackie、3ComキースMcCloghrie、ウォロンゴングループのジム・ロバートソン、3Com脾臓Roselinsky、CMCマーシャルは上昇しました、ウォロンゴングループのジョン・スコット、データゼネラルのルウ・スタインバーグ、IBM
12. References
12. 参照
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, April 1988.
[1] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、1988年4月。
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1065,
August 1988.
[2]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1065、8月1988日
[3] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1066,
August 1988.
[3]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1066、1988年8月。
[4] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC 1098, (Obsoletes
RFC 1067), April 1989.
[4] ケース、J.、M.ヒョードル、M.Schoffstall、およびJ.デーヴィン、「簡単なネットワークマネージメントは(SNMP)について議定書の中で述べます」、RFC。1098 (RFC1067)、1989年4月を時代遅れにします。
[5] ISO 8824: "Information processing systems - Open Systems
[5] ISO8824: 「情報処理システム--Systemsを開いてください」
Warrier & Besaw [Page 49] RFC 1095 CMOT April 1989
Warrier&Besaw[49ページ]RFC1095CMOT1989年4月
Interconnection, Specification of Abstract Syntax Notation One
(ASN.1)", Geneva, March 1988.
「インタコネクト、抽象構文記法1(ASN.1)の仕様」、ジュネーブ、3月1988
[6] ISO 8825: "Information processing systems - Open Systems
Interconnection, Specification of Basic Encoding Rules for
Abstract Notation One (ASN.1)", Geneva, March 1988.
[6] ISO8825: 「情報処理システム--、オープン・システム・インターコネクション、抽象的なNotation OneのためのBasic Encoding RulesのSpecification(ASN.1)、」、ジュネーブ、3月1988
[7] ISO 8649: "Information processing systems - Open Systems
Interconnection, Service Definition for Association Control
Service Element".
[7] ISO8649: 「情報処理システム--、オープン・システム・インターコネクション、アソシエーション制御サービス要素のためのService Definition、」
[8] ISO 8650: "Information processing systems - Open Systems
Interconnection, Protocol Specification for Association
Control Service Element".
[8] ISO8650: 「情報処理システム--、オープン・システム・インターコネクション、アソシエーション制御サービス要素のためのプロトコルSpecification、」
[9] CCITT Recommendation X.219, Working Document for ISO 9072-1:
"Information processing systems - Text Communication, Remote
Operations: Model, Notation and Service Definition",
Gloucester, November 1987.
[9] CCITT推薦X.219、ISO9072-1のための働くドキュメント: 「情報処理システム--テキストCommunication、Remote Operations:、」 「モデル、記法、およびサービス定義」、グロスター、11月1987
[10] CCITT Recommendation X.229, Working Document for ISO 9072-2:
"Information processing systems - Text Communication, Remote
Operations: Protocol Specification", Gloucester,
November 1987.
[10] CCITT推薦X.229、ISO9072-2のための働くドキュメント: 「情報処理システム--テキストCommunication、Remote Operations:、」 「プロトコル仕様」、グロスター、1987年11月。
[11] ISO DIS 9595-2: "Information processing systems - Open
Systems Interconnection, Management Information Service
Definition - Part 2: Common Management Information
Service", 22 December 1988.
[11] ISOは9595-2をけなします: 「情報処理システム--オープン・システム・インターコネクション、Management情報Service Definition--第2部:、」 「共通管理情報サービス」、1988年12月22日。
[12] ISO DIS 9596-2: "Information Processing Systems - Open
Systems Interconnection, Management Information Protocol
Specification - Part 2: Common Management Information
Protocol", 22 December 1988.
[12] ISOは9596-2をけなします: 「情報処理システム--オープン・システム・インターコネクション、経営情報プロトコル仕様--第2部:、」 「共通管理情報プロトコル」、1988年12月22日。
[13] Rose, M., "ISO Presentation Services on top of TCP/IP-based
internets", RFC 1085, December 1988.
[13] ローズ、1988年12月、M.、「TCP/IPベースのインターネットの上のISO Presentation Services」RFC1085。
[14] OSI Network Management Forum, "Forum Interoperable Interface
Protocols", September 1988.
[14]OSIネットワークマネージメントフォーラム、「フォーラムの共同利用できるインタフェースプロトコル」、1988年9月。
[15] ISO DIS 7498-4: "Information processing systems - Open
Systems Interconnection, Basic Reference Model - Part 4:
OSI Management Framework".
[15] ISOは7498-4をけなします: 「情報処理システム(オープン・システム・インターコネクション、Basic Reference Model)は4を分けます」 「OSI管理フレームワーク。」
[16] ISO/IEC JTC1/SC21/WG4 N571: "Information processing systems -
Open Systems Interconnection, Systems Management: Overview",
London, July 1988.
[16] ISO/IEC JTC1/SC21/WG4 N571: 「情報処理システム--オープン・システム・インターコネクション、Systems Management:、」 「概要」、ロンドン、1988年7月。
Warrier & Besaw [Page 50] RFC 1095 CMOT April 1989
Warrier&Besaw[50ページ]RFC1095CMOT1989年4月
[17] Klerer, S. Mark, "The OSI Management Architecture: An
Overview", IEEE Network Magazine, March 1988.
[17]Klerer、S.マーク、「OSI管理体系:」 「概要」、IEEEネットワーク雑誌、1988年3月。
[18] Ben-Artzi, A., "Network Management for TCP/IP Networks: An
Overview", Internet Engineering Task Force working note,
April 1988.
[18]ベン-Artzi、A.、「TCP/IPのためのネットワークマネージメントは以下をネットワークでつなぎます」。 「Overview」、インターネット・エンジニアリング・タスク・フォースの働く注意、1988年4月。
[19] ISO/IEC JTC1/SC21/WG4 N3324: "Information processing
systems - Open Systems Interconnection, Management
Information Services - Structure of Management
Information - Part I: Management Information Model",
Sydney, December 1988.
[19] ISO/IEC JTC1/SC21/WG4 N3324: 「情報処理システム--オープン・システム・インターコネクション、Management情報Services--Management情報の構造--Iを分けてください」 「経営情報モデル」、シドニー、1988年12月。
[20] Postel, J., "User Datagram Protocol", RFC 768, August 1980.
[20] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、1980年8月。
[21] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981.
[21] ポステル、J.、「通信制御プロトコル」、RFC793、1981年9月。
[22] ISO DP 9534: "Information processing systems - Open Systems
Interconnection, Application Layer Structure", 10 March 1987.
[22] ISO DP9534: 「情報処理システム--オープン・システム・インターコネクション、Application Layer Structure、」、1987年3月10日。
[23] Rose, M., "ISO Transport Services on top of the TCP",
RFC 1006, May 1987.
[23] ローズ、1987年5月、M.、「TCPの上のISO Transport Services」RFC1006。
[24] ISO 8822: "Information processing systems - Open Systems
Interconnection, Connection Oriented Presentation Service
Definition", June 1987.
[24] ISO8822: 「情報処理システム--オープン・システム・インターコネクション、Connection Oriented Presentation Service Definition、」、6月1987日
[25] Postel, J., "Internet Protocol", RFC 791, September 1981.
[25] ポステル、J.、「インターネットプロトコル」、RFC791、1981年9月。
[26] CCITT Draft Recommendation X.500, ISO DIS 9594/1-8: "The
Directory", Geneva, March 1988.
[26] CCITT草稿推薦X.500、ISOは9594/1-8をけなします: 「ディレクトリ」、ジュネーブ、1988年3月。
Warrier & Besaw [Page 51] RFC 1095 CMOT April 1989
Warrier&Besaw[51ページ]RFC1095CMOT1989年4月
Appendix A - The CMOT Group
付録A--CMOTグループ
CMOT DEFINITIONS ::= BEGIN
CMOT定義:、:= 始まってください。
IMPORTS OBJECT-TYPE FROM RFC1065-SMI;
RFC1065-SMIからオブジェクト・タイプをインポートします。
IMPORTS mib FROM RFC1066-MIB;
IMPORTS mib FROM RFC1066-MIB。
cmot OBJECT IDENTIFIER ::= { mib 9 }
cmot OBJECT IDENTIFIER:、:= mib9
-- The following assignments are made for the purpose of
-- identification within CMOT and do not refer to MIB objects.
-- そして、目的のために以下の課題をする、--、CMOTの中の識別、MIBオブジェクトを参照しないでください。
cmotVersion OBJECT IDENTIFIER ::= { cmot 1 }
cmotVersionオブジェクト識別子:、:= cmot1
cmotAcseInfo OBJECT IDENTIFIER ::= { cmot 2 }
cmotAcseAccessControl OBJECT IDENTIFIER ::= { cmotAcseInfo 1 }
cmotAcseInfoオブジェクト識別子:、:= cmot2cmotAcseAccessControl OBJECT IDENTIFIER:、:= cmotAcseInfo1
-- The following definition is made for use in referencing a
-- managed system (for the purpose of proxy management) in the
-- CMIP Object Instance field. It does not represent a MIB
-- object.
-- aに参照をつけることにおける使用のために以下の定義をします--中でシステム(プロキシ管理の目的のための)を管理する、--CMIP Object Instance分野。 それはMIBを表しません--反対してください。
cmotSystemID OBJECT-TYPE
SYNTAX CmotSystemID
ACCESS not-accessible
STATUS optional
::= { cmot 3 }
cmotSystemID OBJECT-TYPE SYNTAX CmotSystemID ACCESSのアクセスしやすくないSTATUS任意:、:= cmot3
CmotSystemID ::= CHOICE {
arbitrary [0] IMPLICIT OCTET STRING,
proxyIndex [1] IMPLICIT INTEGER,
inetAddr [2] IMPLICIT IpAddress,
domainName [3] IMPLICIT OCTET STRING,
mac802Addr [4] IMPLICIT OCTET STRING,
x121Addr [5] IMPLICIT OCTET STRING,
nsap [6] IMPLICIT OCTET STRING,
netbiosName [7] IMPLICIT OCTET STRING,
snaName [8] IMPLICIT OCTET STRING,
adminId [9] IMPLICIT OBJECT IDENTIFIER
}
CmotSystemID:、:= 選択任意の[0]IMPLICIT OCTET STRING、proxyIndex[1]IMPLICIT INTEGER、inetAddr[2]IMPLICIT IpAddress、domainName[3]IMPLICIT OCTET STRING mac802Addr[4]IMPLICIT OCTET STRING、x121Addr[5]IMPLICIT OCTET STRING、nsap[6]IMPLICIT OCTET STRING、netbiosName[7]IMPLICIT OCTET STRING、snaName[8]IMPLICIT OCTET STRING、adminId[9]IMPLICIT OBJECT IDENTIFIER
-- All addresses should be conveyed in network-byte order.
-- すべてのアドレスがネットワークバイトオーダーで伝えられるべきです。
END
終わり
Warrier & Besaw [Page 52] RFC 1095 CMOT April 1989
Warrier&Besaw[52ページ]RFC1095CMOT1989年4月
Appendix B - Management Information Summary
付録B--経営情報概要
RFC1066-MIB-INTERPRETATION
RFC1066-MIB-解釈
{ iso org(3) dod(6) internet(1) mgmt(2) 1 }
iso org(3) dod(6)インターネット(1)管理(2)1
DEFINITIONS ::= BEGIN
定義:、:= 始まってください。
IMPORTS mgmt, OBJECT-TYPE FROM RFC1065-SMI;
IMPORTS管理、OBJECT-TYPE FROM RFC1065-SMI。
mib OBJECT IDENTIFIER ::= { mgmt 1 }
mib OBJECT IDENTIFIER:、:= 管理1
system OBJECT IDENTIFIER ::= { mib 1 }
interfaces OBJECT IDENTIFIER ::= { mib 2 }
at OBJECT IDENTIFIER ::= { mib 3 }
ip OBJECT IDENTIFIER ::= { mib 4 }
icmp OBJECT IDENTIFIER ::= { mib 5 }
tcp OBJECT IDENTIFIER ::= { mib 6 }
udp OBJECT IDENTIFIER ::= { mib 7 }
egp OBJECT IDENTIFIER ::= { mib 8 }
システムOBJECT IDENTIFIER:、:= mib1はOBJECT IDENTIFIERを連結します:、:= OBJECT IDENTIFIERのmib2:、:= mib3ip OBJECT IDENTIFIER:、:= mib4icmp OBJECT IDENTIFIER:、:= mib5tcp OBJECT IDENTIFIER:、:= mib6udp OBJECT IDENTIFIER:、:= mib7egp OBJECT IDENTIFIER:、:= mib8
-- definition of object class
-- 物のクラスの定義
OBJECT-CLASS MACRO ::=
BEGIN
TYPE NOTATION ::= SubClassOf Superiors Names Attributes
VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
物クラスマクロ:、:= タイプ記法を始めてください:、:= SubClassOf上司名は値の記法を結果と考えます:、:= 値(値の物の識別子)
SubClassOf ::= "SUBCLASS OF" value(OBJECT-CLASS)
| empty
Superiors ::= "SUPERIORS" "{" SuperiorList "}"
| empty
Names ::= "NAMES" "{" AttributeList "}"
| empty
Attributes ::= "CONTAINS" "{" AttributeList "}"
| empty
SubClassOf:、:= 「」 価値(物クラス)のサブクラス| Superiorsを空にしてください:、:= 「上司」、「"SuperiorList"、」| Namesを空にしてください:、:= 「名前」、「"AttributeList"、」| Attributesを空にしてください:、:= 「含有」、「"AttributeList"、」| 空になってください。
SuperiorList ::= Superior | Superior "," SuperiorList
Superior ::= value(OBJECT-CLASS)
SuperiorList:、:= 上司| 」 「上司」、SuperiorList上司:、:= 値(物クラス)
AttributeList ::= Attribute | Attribute "," AttributeList
Attribute ::= value(OBJECT-TYPE)
AttributeList:、:= 属性| 」 「属性」、AttributeListは以下を結果と考えます:= 値(オブジェクト・タイプ)
END
終わり
-- the System group
-- Systemグループ
Warrier & Besaw [Page 53] RFC 1095 CMOT April 1989
Warrier&Besaw[53ページ]RFC1095CMOT1989年4月
system OBJECT-CLASS
NAMES { cmotSystemID } -- Appendix A
CONTAINS {
sysDescr,
sysObjectID,
sysUpTime
}
::= { mib 1 }
システムOBJECT-CLASS NAMES cmotSystemID--、付録A CONTAINS、sysDescr、sysObjectID、sysUpTime:、:= mib1
-- the Interfaces group
-- Interfacesグループ
interfaces OBJECT-CLASS
SUPERIORS { system }
CONTAINS { ifNumber }
::= { mib 2 }
インタフェースOBJECT-CLASS SUPERIORSシステムCONTAINS ifNumber:、:= mib2
ifTable OBJECT-CLASS
SUPERIORS { interfaces }
::= { interfaces 2 }
ifTable OBJECT-CLASS SUPERIORSは以下を連結します:= インタフェース2
ifEntry OBJECT-CLASS
SUPERIORS { ifTable }
NAMES { ifIndex }
CONTAINS {
ifIndex,
ifDescr,
ifType,
ifMtu,
ifSpeed,
ifPhysAddress,
ifAdminStatus,
ifOperStatus,
ifLastChange,
ifInOctets,
ifInUcastPkts,
ifInNUcastPkts,
ifInDiscards,
ifInErrors,
ifInUnknownProtos,
ifOutOctets,
ifOutUcastPkts,
ifOutNUcastPkts,
ifOutDiscards,
ifOutErrors,
ifOutQLen
}
::= { ifTable 1 }
ifTableがifIndexと命名するifEntry物クラスの上司はifIndex、ifDescr、ifType、ifMtu、ifSpeed、ifPhysAddress、ifAdminStatus、ifOperStatus、ifLastChange、ifInOctets、ifInUcastPkts、ifInNUcastPkts、ifInDiscards、ifInErrors、ifInUnknownProtos、ifOutOctets、ifOutUcastPkts、ifOutNUcastPkts、ifOutDiscards、ifOutErrors、ifOutQLenを含みます:、:= ifTable1
Warrier & Besaw [Page 54] RFC 1095 CMOT April 1989
Warrier&Besaw[54ページ]RFC1095CMOT1989年4月
-- the Address Translation group
-- Address Translationグループ
at OBJECT-CLASS
SUPERIORS { system }
::= { mib 3 }
OBJECT-CLASS SUPERIORSシステムで:、:= mib3
atTable OBJECT-CLASS
SUPERIORS { at }
::= { at 1 }
atTable物クラスの上司、:、:= 1
atEntry OBJECT-CLASS
SUPERIORS { atTable }
NAMES {
atIfIndex,
atNetAddress
}
CONTAINS {
atIfIndex,
atPhysAddress,
atNetAddress
}
::= { atTable 1 }
上司atTableがatIfIndex、atNetAddressと命名するatEntry物クラスはatIfIndex、atPhysAddress、atNetAddressを含みます:、:= atTable1
-- the IP group
-- IPグループ
ip OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
ipForwarding,
ipDefaultTTL,
ipInReceives,
ipInHdrErrors,
ipInAddrErrors,
ipForwDatagrams,
ipInUnknownProtos,
ipInDiscards,
ipInDelivers,
ipOutRequests,
ipOutDiscards,
ipOutNoRoutes,
ipReasmTimeout,
ipReasmReqds,
ipReasmOKs,
ipReasmFails,
ipFragOKs,
ipFragFails,
ipFragCreates
}
ip OBJECT-CLASS SUPERIORSシステムCONTAINSipForwarding、ipDefaultTTL、ipInReceives、ipInHdrErrors、ipInAddrErrors、ipForwDatagrams、ipInUnknownProtos、ipInDiscards、ipInDelivers、ipOutRequests、ipOutDiscards、ipOutNoRoutes、ipReasmTimeout、ipReasmReqds、ipReasmOKs、ipReasmFails、ipFragOKs、ipFragFails、ipFragCreates
Warrier & Besaw [Page 55] RFC 1095 CMOT April 1989
Warrier&Besaw[55ページ]RFC1095CMOT1989年4月
::= { mib 4 }
::= mib4
-- the IP Interface table
-- IP Interfaceテーブル
ipAddrTable OBJECT-CLASS
SUPERIORS { ip }
::= { ip 20 }
ipAddrTable OBJECT-CLASS SUPERIORSは以下をipします:= ip20
ipAddrEntry OBJECT-CLASS
SUPERIORS { ipAddrTable }
NAMES { ipAdEntAddr }
CONTAINS {
ipAdEntAddr,
ipAdEntIfIndex,
ipAdEntNetMask,
ipAdEntBcastAddr
}
::= { ipAddrTable 1 }
ipAddrTableがipAdEntAddrと命名するipAddrEntry物クラスの上司はipAdEntAddr、ipAdEntIfIndex、ipAdEntNetMask、ipAdEntBcastAddrを含みます:、:= ipAddrTable1
-- the IP Routing table
-- IPルート設定テーブル
ipRoutingTable OBJECT-CLASS
SUPERIORS { ip }
::= { ip 21 }
ipRoutingTable OBJECT-CLASS SUPERIORSは以下をipします:= ip21
ipRouteEntry OBJECT-CLASS
SUPERIORS { ipRoutingTable }
NAMES { ipRouteDest }
CONTAINS {
ipRouteDest,
ipRouteIfIndex,
ipRouteMetric1,
ipRouteMetric2,
ipRouteMetric3,
ipRouteMetric4,
ipRouteNextHop,
ipRouteType,
ipRouteProto,
ipRouteAge
}
::= { ipRoutingTable 1 }
ipRoutingTableがipRouteDestと命名するipRouteEntry物クラスの上司はipRouteDest、ipRouteIfIndex、ipRouteMetric1、ipRouteMetric2、ipRouteMetric3、ipRouteMetric4、ipRouteNextHop、ipRouteType、ipRouteProto、ipRouteAgeを含みます:、:= ipRoutingTable1
-- the ICMP group
-- ICMPグループ
icmp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
icmpInMsgs,
icmp OBJECT-CLASS SUPERIORSシステムCONTAINS、icmpInMsgs
Warrier & Besaw [Page 56] RFC 1095 CMOT April 1989
Warrier&Besaw[56ページ]RFC1095CMOT1989年4月
icmpInErrors,
icmpInDestUnreachs,
icmpInTimeExcds,
icmpInParmProbs,
icmpInSrcQuenchs,
icmpInRedirects,
icmpInEchos,
icmpInEchoReps,
icmpInTimestamps,
icmpInTimestampReps,
icmpInAddrMasks,
icmpInAddrMaskReps,
icmpOutMsgs,
icmpOutErrors,
icmpOutDestUnreachs,
icmpOutTimeExcds,
icmpOutParmProbs,
icmpOutSrcQuenchs,
icmpOutRedirects,
icmpOutEchos,
icmpOutEchoReps,
icmpOutTimestamps,
icmpOutTimestampReps,
icmpOutAddrMasks,
icmpOutAddrMaskReps
}
::= { mib 5 }
icmpInErrors、icmpInDestUnreachs、icmpInTimeExcds、icmpInParmProbs、icmpInSrcQuenchs、icmpInRedirects、icmpInEchos、icmpInEchoReps、icmpInTimestamps、icmpInTimestampReps、icmpInAddrMasks、icmpInAddrMaskReps、icmpOutMsgs、icmpOutErrors、icmpOutDestUnreachs、icmpOutTimeExcds、icmpOutParmProbs、icmpOutSrcQuenchs、icmpOutRedirects、icmpOutEchos、icmpOutEchoReps、icmpOutTimestamps、icmpOutTimestampReps、icmpOutAddrMasks、icmpOutAddrMaskReps ::= mib5
-- the TCP group
-- TCPグループ
tcp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
tcpRtoAlgorithm,
tcpRtoMin,
tcpRtoMax,
tcpMaxConn,
tcpActiveOpens,
tcpPassiveOpens,
tcpAttemptFails,
tcpEstabResets,
tcpCurrEstab,
tcpInSegs,
tcpOutSegs,
tcpRetransSegs
}
::= { mib 6 }
tcp OBJECT-CLASS SUPERIORSシステムCONTAINS、tcpRtoAlgorithm、tcpRtoMin、tcpRtoMax、tcpMaxConn、tcpActiveOpens、tcpPassiveOpens、tcpAttemptFails、tcpEstabResets、tcpCurrEstab、tcpInSegs、tcpOutSegs、tcpRetransSegs:、:= mib6
Warrier & Besaw [Page 57] RFC 1095 CMOT April 1989
Warrier&Besaw[57ページ]RFC1095CMOT1989年4月
-- the TCP connections table
-- TCP接続テーブル
tcpConnTable OBJECT-CLASS
SUPERIORS { tcp }
::= { tcp 13 }
tcpConnTable OBJECT-CLASS SUPERIORSは以下をtcpします:= tcp13
tcpConnEntry OBJECT-CLASS
SUPERIORS { tcpConnTable }
NAMES {
tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort
}
CONTAINS {
tcpConnState,
tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort
}
::= { tcpConnTable 1 }
上司tcpConnTableがtcpConnLocalAddress、tcpConnLocalPort、tcpConnRemAddress、tcpConnRemPortと命名するtcpConnEntry物クラスはtcpConnState、tcpConnLocalAddress、tcpConnLocalPort、tcpConnRemAddress、tcpConnRemPortを含みます:、:= tcpConnTable1
-- the UDP group
-- UDPグループ
udp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
udpInDatagrams,
udpNoPorts,
udpInErrors,
udpOutDatagrams
}
::= { mib 7 }
udp OBJECT-CLASS SUPERIORSシステムCONTAINS、udpInDatagrams、udpNoPorts、udpInErrors、udpOutDatagrams:、:= mib7
-- the EGP group
-- EGPグループ
egp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
egpInMsgs,
egpInErrors,
egpOutMsgs,
egpOutErrors
}
::= { mib 8 }
egp OBJECT-CLASS SUPERIORSシステムCONTAINS、egpInMsgs、egpInErrors、egpOutMsgs、egpOutErrors:、:= mib8
Warrier & Besaw [Page 58] RFC 1095 CMOT April 1989
Warrier&Besaw[58ページ]RFC1095CMOT1989年4月
-- the EGP Neighbor table
-- EGP Neighborテーブル
egpNeighTable OBJECT-CLASS
SUPERIORS { egp }
::= { egp 5 }
egpNeighTable OBJECT-CLASS SUPERIORSは以下をegpします:= egp5
egpNeighEntry OBJECT-CLASS
SUPERIORS { egpNeighTable }
NAMES { egpNeighAddr }
CONTAINS {
egpNeighState,
egpNeighAddr
}
::= { egpNeighTable 1 }
egpNeighTableがegpNeighAddrと命名するegpNeighEntry物クラスの上司はegpNeighState、egpNeighAddrを含みます:、:= egpNeighTable1
END
終わり
Warrier & Besaw [Page 59] RFC 1095 CMOT April 1989
Warrier&Besaw[59ページ]RFC1095CMOT1989年4月
Appendix C - Sample Protocol Exchanges
付録C--サンプルプロトコル交換
The following are sample protocol exchanges between a manager and an agent. The manager establishes an association with the agent, requests the number of IP address and header errors, requests the type of route corresponding to the destination address 10.0.0.51, requests the TCP connection with the well-known port for FTP, and then releases the association. All of these samples show the lightweight presentation protocol being used over TCP.
↓これはマネージャとエージェントの間のサンプルプロトコル交換です。 送付先アドレスへのルート対応のタイプがマネージャがエージェントとの仲間を設立して、要求がIPアドレスとヘッダー誤りの数であるよう要求する、10.0、.0、.51、FTPのためにウェルノウンポートとのTCP関係を要求して、次に、協会をリリースします。 これらのサンプルのすべてが、軽量のプレゼンテーションプロトコルがTCPの上で使用されているのを示します。
-- -- the manager sends an ACSE association request carried in a -- presentation connect request PDU --
-- -- マネージャはaで運ばれたACSE協会要求を送ります--プレゼンテーションは要求PDUを接続します--
{
connectRequest { -- LPP
version version-1,
reference {
callingSSUserReference "sri-nic.arpa",
commonReference "880821222531Z"
},
asn 1.3.6.1.2.1.9.1.1,
user-data { -- ACSE
protocol-version version1,
application-context-name 1.3.6.1.2.1.9.1.1,
user-information {
functionalUnits {
direct-reference 1.0.9596.2.1.0.0,
encoding {
single-ASN1-type '010110101010101010110B'
-- Full Manager
}
}
}
}
}
}
connectRequestである、--、LPPバージョンバージョン-1(callingSSUserReference「様-nic.arpa」、commonReference"880821222531Z"という参照)が1.3に.6をasnする.1、.2、.1、.9、.1、.1、利用者データ、ACSEプロトコルバージョンversion1、文脈が命名するアプリケーション1.3、.6 .1 .2 .1 .9 .1 .1、ユーザー情報、functionalUnits、直接的な言及1.0.9596、.2、.1、.0、独身のASN1がタイプしている'010110101010101010110B'--完全なマネージャをコード化する.0
-- -- the agent sends an ACSE association response carried in a -- presentation connect response PDU --
-- -- エージェントはaで運ばれたACSE協会応答を送ります--プレゼンテーションは応答PDUを接続します--
{
connectResponse { -- LPP
user-data {
connectResponse、--、LPP利用者データ
Warrier & Besaw [Page 60] RFC 1095 CMOT April 1989
Warrier&Besaw[60ページ]RFC1095CMOT1989年4月
user-information { -- ACSE
functionalUnits {
direct-reference 1.0.9596.2.1.0.0,
encoding {
single-ASN1-type '101001010101010101110B'
-- Full Agent
}
}
}
}
}
}
ユーザー情報、--、ACSE functionalUnits、直接的な言及1.0.9596、.2、.1、.0、独身のASN1がタイプしている'101001010101010101110B'--完全なエージェントをコード化する.0 } }
-- -- the manager sends a get request to read the values of -- ipInHdrErrors and ipInAddrErrors --
-- -- マネージャが発信する、aは値を読む要求(ipInHdrErrorsとipInAddrErrors)を得ます。
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 10,
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ip { 1.3.6.1.2.1.4 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {}
}
},
attributeIdList {
attributeId {
localID 4 -- ipInHdrErrors
},
attributeId {
localID 5 -- ipInAddrErrors
}
}
}
}
}
}
{ userData { -- LPP ro-Invoke { -- ROSE invokeID 10, operation-value m-Get(3), argument { -- CMIP baseManagedObjectClass { globalForm ip { 1.3.6.1.2.1.4 } }, baseManagedObjectInstance { distinguishedName { relativeDistinguishedName {} } }, attributeIdList { attributeId { localID 4 -- ipInHdrErrors }, attributeId { localID 5 -- ipInAddrErrors } } } } } }
Warrier & Besaw [Page 61] RFC 1095 CMOT April 1989
Warrier&Besaw[61ページ]RFC1095CMOT1989年4月
-- -- the agent replies with a get response indicating that -- ipInHdrErrors = 0 and ipInAddrErrors = 2 --
-- -- aとのエージェント回答で、応答はそれを示します--ipInHdrErrorsは0とipInAddrErrors=2と等しいです--
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 10,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ip { 1.3.6.1.2.1.4 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {}
}
},
currentTime "19880821222541.300000Z",
attributeList {
attribute {
attributeId {
localID 4 -- ipInHdrErrors
},
attributeValue 0
},
attribute {
attributeId {
localID 5 -- ipInAddrErrors
},
attributeValue 2
}
}
}
}
}
}
}
{ userData { -- LPP ro-Result { -- ROSE invokeID 10, { operation-value m-Get(3), argument { -- CMIP baseManagedObjectClass { globalForm ip { 1.3.6.1.2.1.4 } }, baseManagedObjectInstance { distinguishedName { relativeDistinguishedName {} } }, currentTime "19880821222541.300000Z", attributeList { attribute { attributeId { localID 4 -- ipInHdrErrors }, attributeValue 0 }, attribute { attributeId { localID 5 -- ipInAddrErrors }, attributeValue 2 } } } } } } }
-- -- the manager sends a get request to discover the ipRouteType for -- the IP routing entry with ipRouteDest = 10.0.0.51 --
-- -- マネージャは発信します。IPがipRouteDest=10.0.0.51でエントリーを発送して、aはipRouteTypeを発見する要求を得ます--
Warrier & Besaw [Page 62] RFC 1095 CMOT April 1989
Warrier&Besaw[62ページ]RFC1095CMOT1989年4月
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 11,
operation-value m-Get (3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {
attributeValueAssertion {
attributeType ipRouteDest
{ 1.3.6.1.2.1.4.21.1.1 },
attributeValue 10.0.0.51
}
}
}
},
attributeIdList {
attributeId {
localID 8 -- ipRouteType
}
}
}
}
}
}
{ userData { -- LPP ro-Invoke { -- ROSE invokeID 11, operation-value m-Get (3), argument { -- CMIP baseManagedObjectClass { globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 } }, baseManagedObjectInstance { distinguishedName { relativeDistinguishedName { attributeValueAssertion { attributeType ipRouteDest { 1.3.6.1.2.1.4.21.1.1 }, attributeValue 10.0.0.51 } } } }, attributeIdList { attributeId { localID 8 -- ipRouteType } } } } } }
-- -- the agent replies with a get response indicating the appropriate -- route type --
-- -- aとのエージェント回答で、応答は好個を示します--タイプを発送してください--
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 11,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
},
baseManagedObjectInstance {
distinguishedName {
userData、--、LPP ro結果になってください--ローズinvokeID11、操作値は(3)をm得ます、議論、--、CMIP baseManagedObjectClass、globalForm ipRouteEntry、1.3、.6、.1、.2、.1、.4、.21、.1、baseManagedObjectInstance、distinguishedName
Warrier & Besaw [Page 63] RFC 1095 CMOT April 1989
Warrier&Besaw[63ページ]RFC1095CMOT1989年4月
relativeDistinguishedName {
attributeValueAssertion {
attributeType ipRouteDest
{ 1.3.6.1.2.1.4.21.1.1 },
attributeValue 10.0.0.51
}
}
}
},
currentTime "19880821222613.780000Z",
attributeList {
attribute {
attributeId {
localID 8 -- ipRouteType
},
attributeValue "direct"
}
}
}
}
}
}
}
relativeDistinguishedName、attributeValueAssertion、attributeType ipRouteDest、1.3、.6、.1、.2、.1、.4、.21、.1、.1、attributeValue10.0.0、.51 currentTime"19880821222613.780000Z"、attributeList、属性、attributeId、localID8--、ipRouteType、attributeValue「ダイレクト」 } } } } } }
-- -- the manager sends a get request to read the TCP connection with -- the well-known port for FTP. --
-- -- マネージャは発信します。aはTCP接続を読む要求を得ます--FTPのためのウェルノウンポート。 --
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 12,
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm tcpConnTable { 1.3.6.1.2.1.6.13 }
},
userData、--、LPP ro呼び出す、--、ローズinvokeID12、操作値は(3)をm得ます、議論--、CMIP baseManagedObjectClass、globalForm tcpConnTable、1.3、.6、.1、.2、.1、.6、.13
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName { }
}
},
scope oneLevel(1),
filter {
item {
baseManagedObjectInstance、distinguishedName、relativeDistinguishedName、範囲oneLevel(1)、フィルタ、項目
Warrier & Besaw [Page 64] RFC 1095 CMOT April 1989
Warrier&Besaw[64ページ]RFC1095CMOT1989年4月
equality {
attributeType tcpConnLocalPort
{ 1.3.6.1.2.1.6.13.1.3 }
attributeValue 21 -- ftp
}
}
}
attributeIdList { } -- an empty list means all attributes
}
}
}
}
平等、attributeType tcpConnLocalPort、1.3、.6、.1、.2、.1、.6、.13、.1、.3、attributeValue21--ftpします。 attributeIdList -- 空のリストはすべての属性を意味します。 } } }
-- -- the agent replies with a get response providing the desired TCP -- connection information. If more than one TCP connection had -- satisfied the filter condition, a series of one or more linked -- reply PDUs would have been returned before the final get response. --
-- -- aとのエージェント回答で、応答は必要なTCPを提供します--接続情報。 --1つ以上のTCP接続はそうしました--フィルタ状態を満たします、シリーズの1つか以上がリンクされたなら決勝が応答を得る前に回答PDUsを返したでしょう。 --
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 12,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm tcpConnEntry { 1.3.6.1.2.1.6.13.1 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {
attributeValueAssertion {
attributeType { tcpConnLocalAddress },
attributeValue 128.10.0.34
},
attributeValueAssertion {
attributeType { tcpConnLocalPort },
attributeValue 21
},
attributeValueAssertion {
attributeType { tcpConnRemAddress },
attributeValue 0.0.0.0
},
attributeValueAssertion {
attributeType { tcpConnRemPort },
userData、--、LPP ro結果になってください--ローズinvokeID12、操作値は(3)、議論をm得ます;
Warrier & Besaw [Page 65] RFC 1095 CMOT April 1989
Warrier&Besaw[65ページ]RFC1095CMOT1989年4月
attributeValue 0
},
}
}
},
currentTime "19880821222541.300000Z",
attributeList {
attribute {
attributeId {
localId 1 -- tcpConnState
},
attributeValue LISTEN
},
attribute {
attributeId {
localId 2 -- tcpConnLocalAddress
},
attributeValue 128.10.0.34
},
attribute {
attributeId {
localId 3 -- tcpConnLocalPort
},
attributeValue 21
},
attribute {
attributeId {
localId 4 -- tcpConnRemAddress
},
attributeValue 0.0.0.0
},
attribute {
attributeId {
localId 5 -- tcpConnRemPort
},
attributeValue 0
}
}
}
}
}
}
}
attributeValue0 } }, currentTime "19880821222541.300000Z", attributeList { attribute { attributeId { localId 1 -- tcpConnState }, attributeValue LISTEN }, attribute { attributeId { localId 2 -- tcpConnLocalAddress }, attributeValue 128.10.0.34 }, attribute { attributeId { localId 3 -- tcpConnLocalPort }, attributeValue 21 }, attribute { attributeId { localId 4 -- tcpConnRemAddress }, attributeValue 0.0.0.0 }, attribute { attributeId { localId 5 -- tcpConnRemPort }, attributeValue 0 } } } } } } }
Warrier & Besaw [Page 66] RFC 1095 CMOT April 1989
Warrier&Besaw[66ページ]RFC1095CMOT1989年4月
-- -- the manager sends a presentation release request --
-- -- マネージャはプレゼンテーションリリース要求を送ります--
{
releaseRequest { -- LPP
user-data { -- ACSE
reason normal
}
}
}
releaseRequestである、--、LPP利用者データ、--ACSEが標準を推論する
-- -- the agent sends a presentation release response --
-- -- エージェントはプレゼンテーションリリース応答を送ります--
{
releaseResponse { -- LPP
user-data { -- ACSE
reason normal
}
}
}
releaseResponse、--、LPP利用者データ、--ACSEが標準を推論する
Authors' Addresses
作者のアドレス
Unnikrishnan S. Warrier Unisys Corporation 2400 Colorado MS #42-13 Santa Monica, CA 90406
サンタモニカ、Unnikrishnan S.Warrierユニシス社2400のコロラドMS#42-13カリフォルニア 90406
Phone: (213) 453-5196
以下に電話をしてください。 (213) 453-5196
Email: unni@cs.ucla.edu
メール: unni@cs.ucla.edu
Larry Besaw Hewlett-Packard 3404 East Harmony Road Fort Collins, CO 80525
Roadフォートコリンズ、ラリーBesawヒューレット・パッカード3404の東Harmony CO 80525
Phone: (303) 229-6022
以下に電話をしてください。 (303) 229-6022
Email: lmb%hpcndaw@hplabs.hp.com
メール: lmb%hpcndaw@hplabs.hp.com
Warrier & Besaw [Page 67]
Warrier&Besaw[67ページ]
一覧
スポンサーリンク
