RFC1021 日本語訳

Network Working Group                                      C. Partridge
Request For Comment: 1021                                      BBN/NNSC
                                                             G. Trewitt
                                                               Stanford
                                                           October 1987

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1021 BBN/NNSC G.Trewittスタンフォード1987年10月

             THE HIGH-LEVEL ENTITY MANAGEMENT SYSTEM (HEMS)

ハイレベルの実体マネージメントシステム(ヘリ)

STATUS OF THIS MEMO

このメモの状態

   An overview of the RFCs which comprise the High-Level Entity
   Management System is provided.  This system is experimental, and is
   currently being tested in portions of the Internet.  It is hoped that
   this work will help lead to a standard for IP internetwork
   management.  Distribution of this memo is unlimited.

High平らなEntity Management Systemを包括するRFCsの概要を提供します。 このシステムは、実験的であり、現在、インターネットの部分でテストしていることにされます。 この仕事が、IPインターネットワーク管理の規格に通じるのを助けることが望まれています。 このメモの分配は無制限です。

INTRODUCTION

序論

   Until recently, a majority of critical components in IP networks,
   such as gateways, have come from a very small set of vendors.  While
   each vendor had their own set of management protocols and mechanisms,
   the collection was small, and a knowledgeable system administrator
   could be expected to learn them all.

最近まで、ゲートウェイなどのIPネットワークにおける重要な要素の大部分が非常に小さいセットのベンダーから来ています。 各ベンダーには、それら自身の管理プロトコルとメカニズムのセットがありましたが、収集は小さかったです、そして、博識なシステム管理者がそれらを皆、学ぶと予想できました。

   Now, however, the number of vendors has grown quite large, and the
   lack of an accepted standard for management of network components is
   causing severe management problems.  Compounding this problem is the
   explosive growth of the connected IP networks known as the Internet.
   The combination of increased size and heterogeneity is making
   internetwork management extremely difficult.  This memo discusses an
   effort to devise a standard protocol for all devices, which should
   help alleviate the management problem.

今、しかしながら、ベンダーの数はかなり大きくなりました、そして、ネットワーク要素の管理の受け入れられた規格の不足は厳しい管理問題を引き起こしています。この問題を悪化させるのは、インターネットとして知られている接続IPネットワークの爆発的成長です。 増強されたサイズと異種性の組み合わせで、インターネットワーク管理は非常に難しくなっています。 このメモは、すべてのデバイスのために標準プロトコルについて工夫するために取り組みについて議論します。(デバイスは管理問題を軽減するのを助けるはずです)。

   The RFCs that currently define the High-Level Entity Management
   System are this memo along with RFC-1022, 1024, and 1023.  This list
   is expected to change and grow over time, and readers are strongly
   encouraged to check the RFC Index to find the most current versions.

現在High平らなEntity Management Systemを定義するRFCsはRFC-1022に伴うこのメモと、1024と、1023です。 このリストは、時間がたつにつれて変化して、成長すると予想されます、そして、読者が最新版を見つけるためにRFC Indexをチェックするよう強く奨励されます。

MONITORING AND CONTROL

モニターして、そして、制御してください。

   Historically, the IP community has divided network management into
   two distinct types of activities: monitoring and control.  Monitoring
   is the activity of extracting or collecting data from the network or
   a part of the network to observe its behavior.  Control is the
   activity of taking actions to effect changes in the behavior of the
   network or a part of the network in real-time, typically in an
   attempt to improve the network's performance.

歴史的に、IP共同体はネットワークマネージメントを2つの異なったタイプの活動に分割しました: モニターとコントロール。 モニターは振舞いを観測するためにネットワークのネットワークか一部からデータを抜粋するか、または集める活動です。 コントロールはリアルタイムででネットワークの振舞いかネットワークの一部の効果変化に行動を取る活動です、ネットワークの性能を向上させる通常、試みで。

Partridge & Trewitt                                             [Page 1]

RFC 1021                     HEMS Overview                  October 1987

ヤマウズラとTrewitt[1ページ]RFC1021は概要1987年10月にへりを取ります。

   Note that the ability to control presupposes the ability to monitor.
   Changing the behavior of the network without being able to observe
   the effects of the changes is not useful.  On the other hand,
   monitoring without control makes some sense.  Simply understanding
   what is causing a network to misbehave can be useful.

制御する能力がモニターする能力を予想することに注意してください。 変化の効果を観測できないでネットワークの振舞いを変えるのは役に立ちません。 他方では、コントロールのないモニターはなるほどと思います。 ネットワークが何でふらちな事をしているかを単に理解しているのは役に立つ場合があります。

   Control is also a more difficult functionality to define.  Control
   operations other than the most generic, are usually device-specific.
   The problem is not just a matter of providing a mechanism for
   control, but also defining a set of control operations which are
   generally applicable across a diverse set of devices.  Permitting
   remote applications to exercise control over an entity also implies
   the need for a suite of safeguards to ensure that unauthorized
   applications cannot harm the network.

また、コントロールは定義するのが、より難しい機能性です。 通常、最も多くのジェネリック以外の制御機能はデバイス特有です。 問題はメカニズムをコントロールに提供する問題だけではなく、1セットの一般に、さまざまのセットのデバイスの向こう側に適切な制御機能を定義することでもあります。 また、リモートアプリケーションがコントロールを実体に及ぼすことを許可するのが権限のないアプリケーションがネットワークに害を及ぼすことができないのを保証するためにひとそろいの安全装置の必要性を含意します。

   Because monitoring is the key first step, in this initial design of
   the system, the authors have concentrated more heavily on the
   problems of effective monitoring.  Although the basic control
   mechanisms are defined, many components need for control, such as
   strong access control mechanisms, have not been fully defined.

モニターが主要な第一歩であるので、作者はこの初期のシステムの設計では、より大いに有効なモニターの問題に集中しました。 基本制御メカニズムは定義されますが、多くのコンポーネントがコントロールのために定義されなければなりません、強いアクセス管理機構が完全に定義されているというわけではなかったようなもの。

OVERVIEW OF THE HEMS

ヘリの概要

   The HEMS is made up of three parts: a query processor which can
   reside on any addressable entity, an event generator which also
   resides on entities, and applications which know how to send requests
   to the query processor and interpret the replies.  The query
   processor and applications communicate using a message protocol which
   runs over a standard transport protocol.

HEMSは3つの部品で作られます: どんなアドレス可能な実体にもあることができる質問プロセッサ、また、実体にあるイベントジェネレータ、およびどのように質問プロセッサに要求を送って、回答を解釈するかを知っているアプリケーション。 質問プロセッサとアプリケーションは、標準のトランスポート・プロトコルをひくメッセージプロトコルを使用することで伝えます。

The Query Processor

質問プロセッサ

   The query processor is the key to the management system.  It
   interprets all monitoring and control requests.  For optimal network
   management, we would like to see query processors on most network
   entities.

質問プロセッサはマネージメントシステムのキーです。 それはすべてのモニターとコントロール要求を解釈します。 最適のネットワークマネージメントに関しては、ほとんどのネットワーク実体の質問プロセッサを見たいと思います。

   To encourage the implementations of query processors, one of the
   primary goals in designing the query processor was to make it as
   small and simple as possible, consistent with management
   requirements.

質問プロセッサを設計することにおけるプライマリ目標の1つは質問プロセッサの実装を奨励するためには、それをできるだけ小さく簡単にすることでした、管理要件と一致しています。

   Defining the management requirements was no small task, since the
   networking community has not yet reached a consensus about what kinds
   of monitoring information should be available from network entities,
   nor what control functions are required to properly manage those
   entities.  The standards for HEMS were developed through discussions
   with several interest groups, and represent the authors' best effort

管理要件を定義するのは、小さいタスクではありませんでした、ネットワーク共同体がまだどんな種類の監視情報がネットワーク実体から利用可能であるべきであるか、そして、どんなコントロール機能が適切にそれらの実体を管理するのに必要であるかに関するコンセンサスに達していないので。 HEMSの規格がいくつかの営利団体との議論で開発されて、作者のものの代理をする、ベストエフォート型

Partridge & Trewitt                                             [Page 2]

RFC 1021                     HEMS Overview                  October 1987

ヤマウズラとTrewitt[2ページ]RFC1021は概要1987年10月にへりを取ります。

   to distill the varying sets of needs.

異なったセットの必要性を蒸留するために。

   The authors settled on a system which was extensible, robust and
   host-architecture independent, and as simple as possible, consistent
   with the other goals.  Extensibility was essential because it is
   clear that management needs will continue to evolve, and a closed
   system which could not be changed would be obsolete almost as soon as
   it was defined.  Unfortunately, extensibility is also the requirement
   least consistent with simplicity since the need to make the system
   extensible led the authors to use self-describing data formats and an
   interpreted query language.

作者は広げることができて、強健で、ホストアーキテクチャから独立していて、できるだけ簡単であったシステムについて決めました、他の目標と一致しています。 管理の必要性が、発展し続けているのが、明確であるので、伸展性は不可欠でした、そして、ほとんどそれが定義されるとすぐに、変えることができなかったクローズドシステムは時代遅れでしょう。 残念ながら、また、システムを広げることができるようにする必要性が、作者が自己について説明するデータ形式と解釈された照会言語を使用するように導いたので、伸展性は簡単さと最も一致していない要件です。

   A robust system is required if the system is to be useful for
   diagnosing network failures.  If the monitoring system cannot survive
   at least moderate network failures, it is not useful.

強健なシステムがシステムがネットワーク失敗を診断することの役に立つことであるなら必要です。 監視システムが少なくとも適度のネットワーク失敗を乗り切ることができないなら、役に立ちません。

   The query processor is designed to be highly extensible.  An
   application sends the query processor instructions about objects to
   be examined or changed.  The query processor locates the objects in
   its host entity, and performs the requested operations.  The objects
   are self-describing, using the binary-encoding scheme defined in ISO
   Standard ASN.1.  Care has been taken to use a limited set of the
   ASN.1 coding set, so that query processor's handling of data can be
   optimized.

質問プロセッサは、非常に広げることができるように設計されています。 アプリケーションは、調べるか、または変えるためにオブジェクトに関する質問プロセッサ指示を送ります。 質問プロセッサは、ホスト実体でオブジェクトの場所を見つけて、要求された操作を実行します。 ISO Standard ASN.1で定義されたバイナリーをコード化する体系を使用して、オブジェクトは自己に説明しています。 ASN.1コード化セットの限られたセットを使用するために注意したので、データのその質問プロセッサの取り扱いを最適化できます。

   It is a key feature of HEMS that messages to the query processor
   contain multiple instructions.  The authors felt that this would give
   much higher performance than a remote procedure system which limited
   an application to one operation per message.

質問プロセッサへ通信するHEMSに関する重要な特色が複数の指示を含んでいるということです。 作者は、これがアプリケーションを1メッセージあたり1つの操作に制限したリモート手順システムよりはるかに高い性能を与えると感じました。

   The set of maintained objects is standardized across all entities.
   Every entity is required to manage a small set of objects.  In
   addition, entities of a particular type (e.g., a gateway) may be
   required to manage a larger set of objects, which are optional on
   other entities.  Entities are also permitted to make additional,
   entity-specific objects available to applications.  A method for
   discovering the existence of additional objects is defined.

維持されたオブジェクトのセットはすべての実体の向こう側に標準化されます。 あらゆる実体が、小さいセットのオブジェクトを管理するのに必要です。 さらに、特定のタイプ(例えば、ゲートウェイ)の実体が、より大きいセットのオブジェクトを管理するのに必要であるかもしれません。(オブジェクトは他の実体で任意です)。 また、実体で追加していて、実体特有のオブジェクトがアプリケーションに利用可能になることが許可されています。 追加オブジェクトの存在を発見するためのメソッドは定義されます。

   The combination of self-describing data, the ability to add to the
   standard data set, and a query language which can be easily enhanced
   appeared to offer the necessary extensibility.

自己について説明するデータの組み合わせ、標準のデータセットに加える能力、および容易に機能アップできる照会言語は必要な伸展性を提供するように見えました。

Event Generator

イベントジェネレータ

   On many network entities, particularly critical network components
   such as gateways, it is necessary to have a way for the devices to
   send unsolicited status messages to network management centers.  In
   the IP community, these messages have historically been referred to

多くのネットワーク実体、ゲートウェイなどの特に重要なネットワーク要素では、デバイスが求められていないステータスメッセージをネットワークマネージメントセンターに送る方法を持つのが必要です。 IP共同体では、これらのメッセージは歴史的に示されました。

Partridge & Trewitt                                             [Page 3]

RFC 1021                     HEMS Overview                  October 1987

ヤマウズラとTrewitt[3ページ]RFC1021は概要1987年10月にへりを取ります。

   as "traps", but for compatibility with the ISO nomenclature, in the
   HEMS system they are called "events".

「捕らえます」が、ISO用語体系との互換性において、HEMSシステムで、彼らは「イベント」と呼ばれます。

   In the HEMS system, events are handled as slightly specialized
   replies to queries, and are sent to one or more management centers.
   Like all other HEMS messages, events are formatted in ASN.1 format.

HEMSシステムでは、イベントをわずかに専門化している回答として質問に扱って、1つ以上の管理センターに送ります。 他のすべてのHEMSメッセージのように、イベントはASN.1形式でフォーマットされます。

   Each event is given a well-known code, which is standardized across
   all entities.  Provision is also made for entity specific event
   codes.

よく知られるコードを各イベントに与えます。(それは、すべての実体の向こう側に標準化されます)。 また、実体の特定のイベントコードに備えます。

Applications

アプリケーション

   The HEMS expects that applications will be more intelligent than the
   query processor.  Among other functions, the applications will have
   to be able to identify and parse entity-specific values which may be
   returned.

HEMSは、アプリケーションが質問プロセッサよりさらに知的になると予想します。 他の機能の中では、アプリケーションは、返されるかもしれない実体特有の値を、特定して、分析できなければならないでしょう。

   The details of applications are largely not discussed in the HEMS
   specifications because there is very little that needs to be
   standardized.  Applications must send requests using the protocols
   discussed in the next section, but the interfaces the applications
   provide for displaying monitoring or control information are entirely
   application dependent.

ほとんど標準化される必要があるないので、HEMS仕様でアプリケーションの詳細について主に議論しません。 アプリケーションは次のセクションで議論したプロトコルを使用することで要求を送らなければなりませんが、モニターか制御情報を表示するアプリケーションが備えるインタフェースはアプリケーションに完全に依存しています。

Protocols

プロトコル

   Query processors and applications communicate using an application-
   specific monitoring protocol, the High-Level Entity Management
   Protocol (HEMP).  This protocol provides the formatting rules for the
   queries and their replies.

質問プロセッサとアプリケーションは、アプリケーションの特定のモニターしているプロトコル、High-レベルEntity Managementプロトコル(HEMP)を使用することで伝えます。 このプロトコルは質問と彼らの回答のための形式規則を提供します。

   HEMP runs over a standard transport protocol.  There was a certain
   amount of debate in the community about what type of transport
   protocol was best suited for monitoring.  The key issue was how
   reliable monitoring interactions needed to be.

HEMPは標準のトランスポート・プロトコルをひきます。 どんなタイプのトランスポート・プロトコルが最も良かったかに関する共同体でのモニターに適しているある量の討論がありました。 主要な問題はモニターしている相互作用が、どれくらい信頼できる必要があったということでした。

   The authors expect that three types of management activities will
   predominate: status monitoring, firefighting, and event reporting.

作者は、3つのタイプの管理活動が勝つと予想します: 状態モニター、消火、およびイベント報告。

   Status monitoring is envisioned as occasional retrieval of monitoring
   information, possibly in response to the receipt of event messages.
   In these situations, the network is expected to be in good working
   condition, and monitoring exchanges could probably comfortably work
   with an unreliable transport protocol.  The chance of data loss is
   small, and probably not a serious problem since the data is unlikely
   to be so important that it must be reliably delivered.  (However, it
   should be noted that some applications may prefer reliable delivery

状態モニターは監視情報の時々の検索としてことによるとイベントメッセージの領収書に対応して思い描かれます。 これらの状況で、ネットワークが良い労働条件であると予想されて、モニターしている交換はたぶん頼り無いトランスポート・プロトコルでゆったり働くことができました。 データの損失の機会は小さいです、そして、たぶん、データ以来のどんな深刻な問題もそれほど重要でなさそうにはありません。提供されて、それは確かにそうであるに違いありません。 (しかしながら、いくつかのアプリケーションが信頼できる配信を好むかもしれないことに注意されるべきです。

Partridge & Trewitt                                             [Page 4]

RFC 1021                     HEMS Overview                  October 1987

ヤマウズラとTrewitt[4ページ]RFC1021は概要1987年10月にへりを取ります。

   because it is more convenient.)

それが、より便利であるので。)

   Firefighting is a completely different situation.  In this scenario,
   one or more sites are using management applications to try to locate
   and fix a network problem.  Here we must assume that while the
   network functions (i.e., data can get through), it is not very
   healthy.  We should assume that packets are being lost, that network
   routes will be non-optimal and that it is essential that the
   monitoring data (which is presumably diagnostic) get back to the
   application and that control requests are reliably delivered to the
   entity.  In such circumstances, a reliable protocol is essential.

消火は完全に異なった状況です。 このシナリオでは、1つ以上のサイトが、ネットワーク問題を場所を見つけて、修正しようとするために管理アプリケーションを使用しています。 ここで、私たちは、ネットワークが機能しますが(すなわち、データは通ることができます)、それがそれほど健康でないと思わなければなりません。 私たちはパケットが失われていて、ネットワークルートが非最適になって、モニターしているデータ(おそらく、診断している)がアプリケーションに戻って、コントロール要求が実体に確かに提供されるのが、不可欠であると思うべきです。 そのような事情では、信頼できるプロトコルは不可欠です。

   Events provide yet another bit of complexity.  Events contain useful
   status information, but experience suggests that this information
   does not have to be delivered reliably.  If the problem is serious
   enough, it will re-occur and the event will be sent again.
   Furthermore, events will often be sent to more than one management
   center, which would appear to preclude the use of connection-
   oriented, reliable protocols such as TCP for events.

イベントはまだもう1ビットの複雑さを提供しています。 イベントは役に立つ状態情報を含んでいますが、経験は、この情報が確かに提供される必要はないのを示します。 問題が十分重大であるなら、再発するでしょう、そして、再びイベントを送るでしょう。 その上、しばしば1つ以上の管理センターにイベントを送るでしょう。(それは、接続TCPなどの指向の、そして、信頼できるプロトコルのイベントの使用を排除するように見えるでしょう)。

   The current decision has been to establish two possible transport
   options for HEMS.  More experimental systems may use the Versatile
   Message Transaction Protocol (VMTP), an experimental IP transaction
   protocol.  Near term production systems can use a combination of the
   Transmission Control Protocol (TCP) and the User Datagram Protocol
   (UDP), as described in RFC-1022.

現在の決定はHEMSのために2つの可能な輸送オプションを確立することです。より実験用のシステムはVersatile Message Transactionプロトコル(VMTP)を使用するかもしれません、実験IPトランザクションプロトコル。 短期間プロダクションシステムは通信制御プロトコル(TCP)とユーザー・データグラム・プロトコル(UDP)の組み合わせを使用できます、RFC-1022で説明されるように。

Compatibility with Common Management Information Protocol (CMIP)

共通管理情報プロトコルとの互換性(CMIP)

   Several groups have expressed interest in being able to develop
   applications which can use both HEMS and the emerging ISO-defined
   Common Management Information Protocol (CMIP).  It turns out that
   such a co-existence is feasible, and the authors have made an effort
   to accomodate it.

いくつかのグループがHEMSと現れているISOによって定義された共通管理情報プロトコル(CMIP)の両方を使用できるアプリケーションは開発できることへの関心を示しました。 そのような共存が可能であり、作者がそれをaccomodateするように取り組みを作ったと判明します。

   At the highest level, both CMIP and HEMS perform operations on
   objects stored in remote entities, and both systems use ASN.1
   formatting to represent those objects.  This makes it possible to
   develop a standard set of interface routines which can be used to
   access either system, even though underlying mechanics of the systems
   are quite different.

上層部によって、CMIPとHEMSの両方がリモート実体で保存されたオブジェクトに操作を実行します、そして、両方のシステムはそれらのオブジェクトを表すのにASN.1形式を使用します。 これで、使用できるインタフェースルーチンがどちらのシステムにもアクセスするのが標準セットを開発するのにおいて可能になります、システムの基本的な整備士は全く異なっていますが。

Partridge & Trewitt                                             [Page 5]

ヤマウズラとTrewitt[5ページ]