RFC1270 日本語訳
1270 SNMP Communications Services. F. Kastenholz. October 1991. (Format: TXT=26167 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Kastenholz, Editor
Request for Comments: 1270 Clearpoint Research Corporation
October 1991
ワーキンググループF.Kastenholz、コメントを求めるエディタ要求をネットワークでつないでください: 1270Clearpointは社の1991年10月に研究します。
SNMP Communications Services
SNMP情報提供サービス
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Abstract .............................................. 1 2. Introduction .......................................... 1 3. Standardization ....................................... 3 4. Interoperability ...................................... 3 5. To Transport or Not To Transport ...................... 3 6. Connection Oriented vs. Connectionless ................ 6 7. Which Protocol ........................................ 8 8. Security Considerations ............................... 9 9. Appendix .............................................. 9 10. References ........................................... 10 11. Acknowledgements ..................................... 11 12. Author's Address ..................................... 11
1. 要約… 1 2. 序論… 1 3. 標準化… 3 4. 相互運用性… 3 5. 輸送するか、または輸送しないように… 3 6. コネクションレスに対して指向の接続… 6 7. どのプロトコル… 8 8. セキュリティ問題… 9 9. 付録… 9 10. 参照… 10 11. 承認… 11 12. 作者のアドレス… 11
1. Abstract
1. 要約
This memo is being distributed to members of the Internet community as an Informational RFC. The intent is to present a discussion on the issues relating to the communications services for SNMP. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
このメモはInformational RFCとしてインターネットコミュニティのメンバーに配布されています。 意図はSNMPのために情報提供サービスに関連する問題についての議論を提示することです。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。
2. Introduction
2. 序論
This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation.
このドキュメントは、基本的な情報提供サービスがSNMP実装によって使用されることを決定するとき、考えられるために様々な問題について議論します。
As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [8], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community.
RFC1052、インターネットNetwork Management Standards[8]のDevelopmentのためのIAB Recommendationsで報告されるように、TCP/IPベースのインターネットのネットワークマネージメントのための2歯の戦略は引き受けられました。 短期的では、RFC1067で定義されたSimple Network Managementプロトコル(SNMP)はインターネットコミュニティでノードを管理するのに使用されることでした。
SNMP Working Group [Page 1] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[1ページ]RFC1270SNMP情報提供サービス1991年10月
In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework.
長期では、OSIネットワークマネージメントフレームワークの使用は調べられることでした。 2通のドキュメントが経営情報を定義するために製作されました: (RFCはManagement情報(SMI)のStructureを定義しました)。RFC1065とRFC1066。(RFCはManagement Information基地(MIB)を定義しました)。 これらのドキュメントの両方が、SNMPとOSIネットワークマネージメントフレームワークの両方と互換性があるように設計されました。
This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion.
この戦略は短期的にかなり成功していました: インターネットを利用するネットワークマネージメント技術は数カ月以内に研究と商業共同体の両方によってさばかれました。 これの結果、インターネットコミュニティの部分はタイムリーなファッションで処理しやすいネットワークになりました。
In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet-standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [9], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [10]; and, the Simple Network Management Protocol, RFC 1157 [1], which defines the protocol used to manage these objects.
1990年5月に、コアドキュメントは「お勧め」の状態で「標準プロトコル」に登用されました。 そういうものとして、インターネット標準ネットワークマネージメントフレームワークは以下から成ります。 TCP/IPベースのインターネットのためのManagement情報、RFC1155[9]の構造とIdentification([9]はMIBに含まれた管理オブジェクトがどう定義されるかを説明します)。 TCP/IPベースのインターネットのNetwork Managementのための管理Information基地(Network ManagementはMIB、RFC1156[10]に含まれた管理オブジェクトについて説明します)。 そして、以前はよくSimple Network Managementプロトコル、プロトコルを定義するRFC1157[1]をこれらのオブジェクトを管理していました。
In parallel with this activity, documents specifying how to transport SNMP messages over protocols other than UDP/IP have been developed and published: SNMP Over Ethernet [3], SNMP Over OSI [2], and SNMP Over IPX [6] and it would be suprising if more were not developed. These memos have caused a degree of confusion in the community. This document is intended to disperse that confusion by discussing the issues of relevance to an implementor when choosing how to encapsulate SNMP packets.
この活動と平行して、UDP/IP以外のプロトコルの上でSNMPメッセージを輸送する方法を指定するドキュメントが、開発されて、発表されました: 以上が開発されないなら、SNMP Overイーサネット[3]、SNMP Over OSI[2]、SNMP Over IPX[6]、およびそれはsuprisingされているでしょうに。 これらのメモは共同体の混乱の度合いを引き起こしました。 このドキュメントがパケットをSNMPにカプセルに入れる方法を選ぶとき関連性の問題について作成者と議論することによってその混乱を分散することを意図します。
None of these documents have been made full Internet Standards. SNMP Over ISO and SNMP Over Ethernet are both Experimental protocols. SNMP Over IPX [6] is an Internet Draft. Only the SNMP Specification [1] is an Internet Standard.
これらのドキュメントのいずれは人工の完全なインターネットStandardsではありません。 SNMP Over ISOとSNMP Overイーサネットは両方のExperimentalプロトコルです。 SNMP Over IPX[6]はインターネットDraftです。 唯一のSNMP Specification[1]はインターネットStandardです。
No single transport scheme can be considered the absolute best solution for all circumstances. This note will argue that, except for a very small set of special circumstances, operating SNMP over UDP/IP is the optimal scheme.
すべての事情のための絶対最も良いソリューションであるとどんなただ一つの輸送体系も考えることができません。 この注意は、UDP/IPの上でSNMPを操作するのが、非常に小さい特殊事情以外の最適の体系であると主張するでしょう。
This document does not present a standard or a protocol for the Internet Community. For production use in the Internet the SNMP and its required communication services are specified in [1].
このドキュメントはインターネット共同体のために規格かプロトコルを提示しません。 インターネットでの生産使用として、SNMPとその必要な通信サービスは[1]で指定されます。
SNMP Working Group [Page 2] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[2ページ]RFC1270SNMP情報提供サービス1991年10月
3. Standardization
3. 標準化
Currently, the SNMP Specification [1] only specifies that the UDP protocol be used to exchange SNMP messages. While the IAB may standardize other protocols for use in exchanging SNMP messages in the future, only UDP is currently standardized for this purpose.
現在、SNMP Specification[1]は、UDPプロトコルがSNMPメッセージを交換するのに使用されると指定するだけです。 IABが将来SNMPメッセージを交換することにおける使用のために他のプロトコルを標準化しているかもしれない間、UDPだけが現在、このために標準化されます。
In order to claim full compliance with the SNMP Specification, an implementation would have to use UDP for SNMP message exchange.
SNMP Specificationへの完全なコンプライアンスを要求して、実装はSNMP交換処理にUDPを使用しなければならないでしょう。
4. Interoperability
4. 相互運用性
Interoperability is the degree to which the equipment produced by one vendor can can operate with equipment produced by another vendor.
相互運用性は設備が別のベンダーによって生産されている状態であるベンダー缶によって生産された設備が作動できる度合いです。
Related to Interoperability is compliance with a standard. Everything else being equal, a device that complies with some standard is more likely to be interoperable than a device that does not.
Interoperabilityに関連されるのは、規格への承諾です。 ものが他の何もかも等しくて、何らかの規格に従うデバイスはそうしないデバイスより共同利用できる傾向があります。
For commercial product development, the pros and cons of developing an interoperable product must be weighed and a choice made. Both engineering and marketing organizations participate in this process.
商品開発のために、共同利用できる製品を開発する賛否両論は、重さがあってされた選択でなければなりません。 工学とマーケティング組織の両方がこのプロセスに参加します。
The Internet is the single largest market for SNMP systems. A large portion of SNMP systems will be developed with the Internet as a target environment. Therefore, it may be expected that the Internet's needs and requirements will be the driving force for SNMP. SNMP over UDP/IP is specified as the "Internet Standard" protocol. Therefore, in order to operate in the Internet and be managed in that environment on a production basis, a device must support SNMP over UDP/IP. This situation will lead to SNMP over UDP/IP being the most common method of operating SNMP. Therefore, the widest degree of interoperability and widest acceptance of a commercial product will be attained by operating SNMP over UDP/IP.
インターネットはSNMPシステムの単一の最も大きい市場です。SNMPシステムの大半は目標環境としてインターネットで開発されるでしょう。 したがって、インターネットの必要性と要件がSNMPのために原動力になると予想されるかもしれません。 UDP/IPの上のSNMPは「インターネット規格」プロトコルとして指定されます。 したがって、インターネットで作動して、生産ベースでその環境で管理されるために、デバイスはUDP/IPの上でSNMPをサポートしなければなりません。 この状況は、最も一般的な運用法SNMPであるのでUDP/IPの上でSNMPに通じるでしょう。 したがって、UDP/IPの上でSNMPを操作することによって、最も広い度合いの相互運用性と商品の最も広い承認に達するでしょう。
The preponderance of UDP/IP based network management stations also strongly suggests that an agent should operate SNMP over UDP/IP.
また、UDP/IPのベースのネットワークマネージメントステーションの優勢は、エージェントがUDP/IPの上でSNMPを操作するべきであると強く示唆します。
The results of the interoperability decision drive a number of technical decisions. If interoperability is desired, then SNMP must be operated over UDP/IP.
相互運用性決定の結果は多くの技術的判断を追い立てます。 相互運用性が望まれているなら、UDP/IPの上でSNMPを操作しなければなりません。
5. To Transport or Not To Transport
5. 輸送するか、または輸送しません。
A major issue is whether SNMP should run on top of a transport-layer protocol (such as UDP) or not. Typically, the choice is to run over a transport/network/data link protocol or just run over the datalink. In fact, several protocols have been published for operating SNMP over
主要な問題はSNMPがトランスポート層プロトコル(UDPなどの)の上で稼働するはずであるかどうかということです。 選択は、通常、輸送/ネットワーク/データリンクプロトコルをひくか、またはただデータリンクをひくことです。 事実上、いくつかのプロトコルが操作SNMPのために発表された、終わっている。
SNMP Working Group [Page 3] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[3ページ]RFC1270SNMP情報提供サービス1991年10月
several different datalink and transport protocols.
いくつかの異なったデータリンクとトランスポート・プロトコル。
Operation of SNMP over a Transport and Network protocol stack is preferred. These protocols provide at least five functions that are of vital importance to the movement of SNMP packets through a network:
TransportとNetworkプロトコル・スタックの上のSNMPの操作は好まれます。 これらのプロトコルはネットワークを通したSNMPパケットの動きへの不可欠な重要性のものである少なくとも5つの機能を提供します:
o Routing
The network layer provides routing functions, which
improves the overall utility of network management. The
network has the ability to re-route packets around failed
areas. This allows network management to continue
operating during localized losses of service (It should
be noted that these losses of service occur not only
because of failures, but also for non-failure reasons
such as preventive maintenance).
o ネットワーク層を発送すると、経路選択機能は提供されます(ネットワークマネージメントの総合的なユーティリティを改良します)。 ネットワークには、失敗した領域の周りでパケットを別ルートで送る能力があります。 これで、ネットワークマネージメントは、サービスの限局性欠損の間、作動し続けることができます(失敗のために発生するだけではなく、これらのサービスの損失が予防保守などの非失敗理由でも発生することに注意されるべきです)。
o Media Independence
The network layer provides a high degree of media
independence. By using this capability, many different
types of network elements may be managed. Tying SNMP to
a particular data link protocol limits the management
scope of those SNMP entities to just those devices that
use that datalink protocol.
o ネットワーク層が高度合いのメディア独立を供給するメディアIndependence。 この能力を使用することによって、多くの異なったタイプのネットワーク要素は管理されるかもしれません。 特定のデータリンクプロトコルへのタイイングSNMPはそれらのSNMP実体の管理範囲をまさしくそのデータリンクプロトコルを使用するそれらのデバイスに制限します。
o End-to-End Checksum
The end-to-end checksum provided by transport protocols
improves the reliability of the data transfer.
o 終わりから終わりへの終わりから終わりへのチェックサムがトランスポート・プロトコルで提供したChecksumはデータ転送の信頼性を改良します。
o Multiplexing/Demultiplexing
Transport protocols provide multiplexing and
demultiplexing services. These services facilitate the
many-to-many management relationships possible with SNMP.
o マルチプレクシング/逆多重化Transportプロトコルはマルチプレクシングと逆多重化サービスを提供します。 これらのサービスが多くを多くに容易にする、SNMPで可能な管理関係。
o Fragmentation and Reassembly
This is related to media independence. IP allows SNMP
packets to transit media with differing MTU sizes. This
capability is not available for datalink specific
transmission schemes.
o 断片化とReassembly Thisはメディア独立に関連します。 IPは異なったMTUサイズでトランジットメディアへのパケットをSNMPに許容します。 この能力はデータリンクの特定のトランスミッション体系に利用可能ではありません。
Fragmentation and Reassembly does reduce the overall
robustness of network management since, if any single
fragment is lost along the way, the operation will fail.
The worse the network operates, the higher the
probability that a fragment will get lost or delayed.
For monitoring and data gathering while the network is
operating normally, Fragmentation and Reassembly is not a
problem. When the network is operating poorly (and the
何かただ一つの断片が道に沿ってなくされていると、操作が失敗するので、断片化とReassemblyはネットワークマネージメントの総合的な丈夫さを減少させます。 ネットワークが、よりひどく作動すれば作動するほど、失われているか、または断片が遅れるという確率は、より高いです。 モニターとデータに関しては、ネットワークが通常、作動して、FragmentationとReassemblyである間、集まるのは、問題ではありません。 そしてネットワークが不十分に作動している、(。
SNMP Working Group [Page 4] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[4ページ]RFC1270SNMP情報提供サービス1991年10月
network operators are typically trying to diagnose and
repair a failure), small packets should to be used,
preventing the packet from being fragmented.
オペレータが通常診断しようとしているネットワークと修理a失敗)、小型小包は断片化されるのからの使用されて、防ぐことへのパケットがそうするべきです。
There are other services and functions that are provided by a connection oriented transport. These services and functions are not desired for SNMP. A later section will explore this issue in more detail.
他のサービスがありました、そして、接続によって提供される機能は輸送を適応させました。 これらのサービスと機能はSNMPのために望まれていません。 後のセクションはさらに詳細にこの問題を探るでしょう。
The main drawbacks that are cited with respect to using Transport and Network layers in the managed object are: a) Increased development time and b) Increased resource requirements. These arguments are less than compelling.
管理オブジェクトにTransportとNetwork層を使用することに関して引用される主な欠点は以下の通りです。 a) 増強された開発時間とb) リソース要件を増強しました。 これらの議論はあまり無視できなくはありません。
There are several excellent public domain or freely redistributable UDP/IP stacks that provide enough support for SNMP. The effort required to port the essential components of one of these stacks is small compared to the overall effort of installing the SNMP software.
いくつかの素晴らしい公共の場が自由にあります。SNMPのサポートを十分に提供するredistributable UDP/IPスタック。 SNMPソフトウェアをインストールする総合的な取り組みと比べて、これらのスタックの1つの必須成分を移植するのに必要である取り組みは小さいです。
The additional resources required in the managed object to support UDP/IP are minimal. CPU resources are required only when actually transmitting or receiving a packet. The largest single resource requirement of a UDP/IP is calculating the UDP checksum, which is very small compared to the cost of doing the ASN.1 encoding/decoding, Object Identifier lookup, and so on.
UDP/IPをサポートするのに管理オブジェクトで必要である追加リソースは最小限です。 実際にパケットを伝えるか、または受けるときだけ、CPUリソースが必要です。 UDP/IPの最も大きいただ一つのリソース要件はUDPチェックサムについて計算しています。(ASN.1コード化/解読、Object Identifierルックアップなどをする費用と比べて、それは、非常に小さいです)。
The author has personal knowledge of a UDP/IP stack that was developed expressly for the purpose of supporting SNMP. This stack requires less than 4Kb of code space. It is a minimalist implementation of UDP/IP in that it is "just enough" so support SNMP. This stack supports UDP, IP, ARP, and handles ICMP redirect and echo request messages. Furthermore, this stack was developed by a single person in approximately two months. Obviously, neither the development effort nor the memory requirements are large.
作者には、SNMPをサポートする目的のために明白に開発されたUDP/IPスタックに関する自分自身での認識があります。 このスタックは4KB未満のコードスペースを必要とします。 「ちょうど十分である」のでそれがUDP/IPのミニマリスト実装であるので、SNMPをサポートしてください。 このスタックはUDP、IP、ARP、ICMPが向け直すハンドル、およびエコー要求にメッセージをサポートします。 その上、このスタックはおよそ2カ月で1人の人によって開発されました。 明らかに、開発努力もメモリ要件も大きくはありません。
The network overhead of using UDP/IP is relatively small. A UDP/IP header requires 28 octets (assuming no IP options). Since the UDP is connectionless, it will generate no overhead traffic of its own (such as TCP SYNs, FINs, and ACKs).
UDP/IPを使用するネットワークオーバーヘッドは比較的わずかです。 UDP/IPヘッダーは28の八重奏を必要とします(IPオプションを全く仮定しないで)。 UDPがコネクションレスであるので、それはそれ自身(TCP SYNsや、FINsや、ACKsなどの)のオーバーヘッド・トラヒックを全く生成しないでしょう。
The growing popularity of internetworking outside of The Internet mandates that SNMP operate over, at least, a network layer protocol. These internetworks consist of a number of networks all connected together with routers. In order to traverse a router, a packet must be one of the network layer protocols that the router understands. Therefore, for SNMP management to be deployed in an internetwork, the SNMP entities in that internetwork must use a network layer protocol. SNMP over a datalink can not traverse a router.
SNMPが少なくともネットワーク層プロトコルの上で操作するインターネット命令における外のインターネットワーキングのうなぎ登りの人気。 これらのインターネットワークはルータと共に接続された多くのネットワークから皆、成ります。 ルータを横断するために、パケットはルータが理解しているネットワーク層プロトコルの1つでなければなりません。 したがって、SNMP管理がインターネットワークで配布されるために、そのインターネットワークにおけるSNMP実体はネットワーク層プロトコルを使用しなければなりません。 データリンクの上のSNMPはルータを横断できません。
SNMP Working Group [Page 5] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[5ページ]RFC1270SNMP情報提供サービス1991年10月
There are some circumstances where running SNMP over some datalink is appropriate.
いくつかの事情が何らかのデータリンクの上の実行しているSNMPが適切であるところにあります。
There are schemes are under development to provide Out-Of-Band (OOB) management access to network devices. This OOB access is typically provided over point-to-point or dial-up connections. Since these connections are dedicated to OOB network management and go directly from the network management station to the managed device, a Transport/Network protocol may not be necessary.
あります。体系は、バンドのOut(OOB)に管理アクセスを供給するためにネットワークデバイスに開発中です。 このOOBアクセスをポイントツーポイントかダイアルアップ接続の上に通常提供します。 これらの接続がOOBネットワークマネージメントに捧げられて、直接ネットワークマネージメントステーションから管理されたデバイスまで行くので、Transport/ネットワーク・プロトコルは必要でないかもしれません。
Using a Transport/Network protocol on these links may be easier from a development point of view though. It is probably a simple configuration operation to have the management station's IP use a serial port rather than the "normal" (e.g., Ethernet) port for traffic destined for a particular node.
もっとも、これらのリンクの上にTransport/ネットワーク・プロトコルを使用するのは開発観点から、より簡単であるかもしれません。 管理局のIPに特定のノードのために運命づけられたトラフィックに「正常な」(例えば、イーサネット)ポートよりむしろシリアルポートを使用させるのは、たぶん簡単な構成操作です。
If the Out-Of-Band link is also used as a "primary" route to some nodes, then the functions of a network-layer are required. These functions are readily supplied by using UDP/IP.
また、バンドのOutリンクが「プライマリ」のルートとしていくつかのノードに使用されるなら、ネットワーク層の関数が必要です。 UDP/IPを使用することによって、容易にこれらの機能を供給します。
For a datalink interface and driver (e.g., a PC Ethernet interface card) that must be manageable independent of the higher level protocol suite (which might NOT be manageable), operating SNMP directly over the datalink is reasonable. It is not known, a priori, what higher-level protocol services may be available, so those services can not be used. If an arbitrary choice is made for example, to put in an elementary UDP/IP stack, then there may be two independent UDP/IPs in the system (which is undesireable as this would require two IP addresses per managed node), or a new protocol stack will be introduced into the environment.
より高い平らなプロトコル群(処理しやすくないかもしれない)の如何にかかわらず処理しやすいに違いないデータリンクインタフェースとドライバー(例えば、PCイーサネットインタフェースカード)にとって、データリンクの直接上でSNMPを操作するのは妥当です。 それらのサービスを利用できないようにどんな上位レベル・プロトコルサービスが利用可能であるかもしれないかが先験的に知られていません。 例えば、初等のUDP/IPスタックを入れるために気紛れな選択をするなら、システム(これは管理されたノードあたり2つのIPアドレスを必要とするでしょう、したがって、「非-望-可能」である)には2独立しているUDP/IPsがあるかもしれませんか、または新しいプロトコル・スタックは環境に取り入れられるでしょう。
6. Connection Oriented vs. Connectionless
6. コネクションレスに対する指向の接続
While this section primarily addresses itself to transport layer issues, its basic discussion of connection oriented vs connectionless applies to any layer which provides communication services for SNMP.
このセクションは主としてトランスポート層問題に話しかけますが、コネクションレスに対して指向の接続の基本的な議論は通信サービスをSNMPに供給するどんな層にも適用されます。
For SNMP, connectionless transport service (UDP) is specified in the Protocol Specification [1]. This choice was made after careful study and consideration by the original SNMP developers.
SNMPとして、コネクションレスな輸送サービス(UDP)はプロトコルSpecification[1]で指定されます。 この選択は慎重な研究と考慮の後にオリジナルのSNMP開発者によってされました。
The prime motivation of this choice is that SNMP must continue to operate (if at all possible) when the network is operating at its worst. For other applications, such as Telnet or FTP, the user can always "try again later" if the network is operating poorly. On the other hand, the major purpose of a network management protocol is to fix the network when it is operating poorly so the "try again later" strategy is useless.
この選択の主要な動機はSNMPが、(できれば、)ネットワークが最悪の場合には作動しているとき、作動し続けなければならないということです。 TelnetかFTPなどの他のアプリケーションのために、ネットワークが不十分に作動しているなら、ユーザはいつも「再び、後で試みることができます」。 他方では、ネットワーク管理プロトコルの主要な目的が不十分に作動しているとき、ネットワークを固定することであるので、「後でもう一度試みてください」戦略は役に立ちません。
SNMP Working Group [Page 6] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[6ページ]RFC1270SNMP情報提供サービス1991年10月
By using a connectionless transport protocol, SNMP takes on the responsibility of reliable data transmission (A SNMP application may time out outstanding requests and either retransmit them or abort them as appropriate). However, the SNMP requires these functions only of the sender of a Request PDU (get, getNext, or Set), which typically is a network management station. Since the Agent only generates responses, it need not perform any of these functions. This vastly reduces the resource and functional requirements on the Agent.
コネクションレスなトランスポート・プロトコルを使用することによって、SNMPが確実な資料送信の責任を引き受ける、(SNMPアプリケーションがそうするかもしれない、傑出している要求とどちらかが適切な状態でそれらを再送するか、またはそれらを中止するタイムアウト) しかしながら、SNMPがRequest PDUの送付者だけのこれらの機能を必要とする、(得る、getNext、またはSet、)、通常、ネットワークマネージメントステーションである。 エージェントが応答を生成するだけであるので、それはこれらの機能のいずれも実行する必要はありません。 これは広大にエージェントに関するリソースと機能条件書を減らします。
If a connection oriented transport is used, then a fundamental design choice must be made with respect to connection maintenance:
接続指向の輸送が使用されているなら、接続メインテナンスに関して基本的なデザイン選択をしなければなりません:
(1) Keep a connection open to each managed object on the
network,
(1) ネットワークで各管理オブジェクトに開かれているように接続を保ってください。
(2) Establish and tear down connections on a per-operation
basis, or
または(2) 1操作あたり1個のベースで接続を確立して、取りこわしてください。
(3) Keep a fixed number of connections open and, when another
connection is needed, use some algorithm (e.g., LRU) to
select one for closing and opening to the new agent.
(3) 接続の定数を開くように保ってください、そして、別の接続が必要であったら何らかのアルゴリズム(例えば、LRU)を使用して、新しいエージェントに閉じて、公開するための1つを選択してください。
All of these alternatives pose severe problems, and because of them, each is undesirable.
これらの代替手段のすべてが厳しい問題を引き起こします、そして、それらのために、それぞれが望ましくありません。
The first option reduces the amount of resources required to perform a single operation in that the connection establishment and termination cost is "amortized" over many operations. On the other hand, keeping a connection open implies that the management station needs to maintain a large number of connection records (in the hundreds or even thousands). Furthermore, if either side of the connection engages in "keep-alives" (even though such behavior is frowned upon), a large amount of traffic will be generated, consuming a large amount of network resources, all for no gain.
第1の選択は設立と終了がかかる接続が多くの操作の上で「清算される」のでただ一つの操作を実行するのに必要であるリソースの量を減少させます。 他方では、接続を開くように保つのは、管理局が、多くの接続記録(数百か同等の数千における)を保守する必要であるのを含意します。 その上、接続のどちらの側面も「生活費アリフ」に従事していると(そのような振舞いは反対されますが)、多量のトラフィックは生成されるでしょう、多量のネットワーク資源を消費して、すべてどんな利得のためにも、そうしません。
The second option reduces the amount of idle resources such as connection records, but vastly increases the amount of resources required to perform an operation. A connection must be established, the request Message sent and the response returned, and then the connection closed for each operation. For a TCP, this would typically require 10 separate packet transfers plus the TCP Time-Wait (see the Appendix for details).
2番目のオプションは、接続記録などの遊休資源の量を減少させますが、広大に操作を実行するのに必要であるリソースの量を増強します。 接続を確立しなければなりませんでした、そして、要求Messageは発信しました、そして、応答は戻りました、そして、次に、接続は各操作のために閉じました。 TCPに関しては、これは10回の別々のパケット転送とTCP Time-待ちを通常必要とするでしょう(詳細に関してAppendixを見てください)。
In the face of pathological network problems, a connection oriented transport protocol may simply cease to operate because the probability of getting all of these packets through reduces to a very small number.
病理学的なネットワーク問題に直面して、接続指向のトランスポート・プロトコルは、これらのパケットのすべてを通り抜けるという確率が非常に少ない数まで減少するので作動するのを単にやめるかもしれません。
SNMP Working Group [Page 7] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[7ページ]RFC1270SNMP情報提供サービス1991年10月
The third option requires that the management station maintain connection usage information in order to implement the LRU algorithm. This excessively complicates the management station. Furthermore, this option tends to reduce to the second option when doing health check polling for a number of agents that is large compared to the number of supported connections.
3番目のオプションは、管理局がLRUアルゴリズムを実装するために接続用法情報を保守するのを必要とします。 これは管理局を過度に複雑にします。 その上、このオプションは、多くのサポートしている接続の数と比べて、大きいエージェントのための検診世論調査をするとき、2番目のオプションに減少する傾向があります。
A connection oriented transport protocol may provide services that are undesirable or unneeded by SNMP.
接続指向のトランスポート・プロトコルはSNMPで望ましくないか、または不要なサービスを提供するかもしれません。
For example, one application of network management is to poll nodes to determine if they are up or not. When a node is up, it makes little difference whether SNMP operates over TCP or UDP. However, if the node goes down then TCP will eventually close the connection. Every poll request must then be translated into a TCP Open request while the managed node is down. Once the node comes up, the send must then be done.
例えば、彼らが上がるかどうか決定するために、投票ノードにはネットワークマネージメントの1つの利用があります。 ノードが上がっているとき、SNMPがTCPかUDPの上で作動するか否かに関係なく、それは大差がありません。 しかしながら、ノードが落ちると、TCPは結局、接続を終えるでしょう。 そして、管理されたノードが下がっている間、あらゆる投票要求をTCPオープン要求に翻訳しなければなりません。 一度、ノードが来る、必須を送ってください、そして、次に、してください。
For connection oriented transports, the transport ACK does not necessarily indicate delivery of data to the destination application process (for TCP, see section 2.6 of [4]). The SNMP would still need its own timeout/retry procedure to ensure that the SNMP software actually got the packet.
接続指向の輸送のために、輸送ACKは必ずデータの配送を目的地アプリケーション・プロセスに示すというわけではありません。(TCPに関しては、セクション2.6の[4])を見てください。 SNMPは、SNMPソフトウェアが実際にパケットを得たのを保証するためにまだそれ自身のタイムアウト/再試行手順を必要とするでしょう。
A connection oriented transport such as TCP provides flow control for the data stream. Because of the lock-step nature of SNMP protocol exchanges, this is not a service that SNMP requires.
TCPなどの接続指向の輸送はデータ・ストリームのためのフロー制御を提供します。 SNMPプロトコル交換の堅苦しい本質のために、これはSNMPが必要とするサービスではありません。
Architectural purists may argue that an "Application" layer entity (SNMP) must not perform operations that are properly the realm of the Transport layer (timeouts, retransmissions, and so on). While architecturally pure, this line of reasoning is not relevant. The network management applications and protocols are monitoring the "health" of the network and, as a result, have the best information and are in the best position to adapt their own behavior to the state of the network, and thereby, continuing operations in the face of network adversity.
建築純粋主義者は、「アプリケーション」層の実体(SNMP)が適切に、Transportの分野が層にされるということである操作(タイムアウト、「再-トランスミッション」など)を実行してはいけないと主張するかもしれません。 建築上純粋ですが、推理のこの系列は関連していません。 ネットワークマネージメント利用とプロトコルは、ネットワークの「健康」をモニターしていて、その結果最も良い情報を持って、ネットワークの事情、およびその結果、ネットワーク逆境に直面して継続事業にはそれら自身の振舞いを適合させる最も良い立場にあります。
7. Which Protocol
7. どのプロトコル
The final point of discussion is the actual choice of a protocol to support SNMP.
議論の最終的なポイントはSNMPをサポートするプロトコルの実際の選択です。
If a device is destined for use in the Internet then it must operate SNMP over UDP/IP.
デバイスがインターネットでの使用のために運命づけられているなら、それはUDP/IPの上でSNMPを操作しなければなりません。
If the device is operating in some other protocol environment, then SNMP ought to use the transport services that are native to that
デバイスがある他のプロトコル環境で作動しているなら、SNMPはそのネイティブである輸送サービスを使用するべきです。
SNMP Working Group [Page 8] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[8ページ]RFC1270SNMP情報提供サービス1991年10月
environment. It may make very little sense to introduce a new protocol stack into a network in order to provide just one service. For example, it could require that the network operations staff understand and be able to administer and operate two protocol stacks, that hosts and routers understand both protocols, and so on. It may also be bureaucratically impossible to introduce UDP/IP into the environment (the "We are only a FOONET shop - if it doesn't speak FOONET, we don't want it" argument).
環境。 それはちょうど1つのサービスを提供するために新しいプロトコル・スタックをネットワークに取り入れる非常に小さい意味になるかもしれません。 例えば、それは、ネットワーク操作スタッフが2個のプロトコル・スタックを理解して、管理して、操作できて、ホストとルータがプロトコルなどの両方を理解しているのを必要とするかもしれません。 また、環境(「私たちはFOONET店にすぎません--それがFOONETを話さないなら、私たちは、それが欲しいと思わない」という議論)にUDP/IPを取り入れるのもbureaucraticallyに不可能であるかもしれません。
References [2] and [6] are experimental standards for operating SNMP over IPX and OSI respectively. In these environments, those standards ought to be adhered to.
参照[2]と[6]はIPXとOSIの上でそれぞれSNMPを操作する実験規格です。 これらの環境で、それらの規格は固く守られるべきです。
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Appendix
9. 付録
This appendix details the TCP packet transfers required to perform a single SNMP operation assuming that the connection is established only for that operation and that a single SNMP operation (e.g., get request) is performed. We also assume that all operations are "normal" i.e., that there are no lost packets, no simultaneous opens, no half opens, and no simultaneous closes. We also ignore the possibility of TCP segmentation and IP fragmentation.
この付録は転送が接続がその操作のためだけに確立されて、ただ一つのSNMP操作(例えば、要求を得る)が実行されると仮定しながらただ一つのSNMP操作を実行するのを必要としたTCPパケットについて詳述します。 いいえはパケットで、同時でなく失われた開いて、半分は全く開きません、そして、いいえ。また、私たちが、すなわち、すべての操作が「正常である」と思う、ある、同時の閉鎖。 また、私たちはTCP分割とIP断片化の可能性を無視します。
The nomenclature used to illustrate the packet transactions is the same as that used in the TCP Specification [4].
パケットトランザクションを例証するのに使用される用語体系はTCP Specification[4]で使用されるそれと同じです。
SNMP Working Group [Page 9] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[9ページ]RFC1270SNMP情報提供サービス1991年10月
Packet Management Managed
Number Station Object
Connection Open...
1 >--<CTL=SYN>----------------------->
2 <--<CTL=SYN,ACK>-------------------<
3 >--<CTL=ACK>----------------------->
Connection now open,
SNMP Request is sent.
4 >--<DATA=SNMP Request>------------->
Response comes back
5 <--<DATA=SNMP Response, CTL=ACK>---<
6 >--<CTL=ACK>----------------------->
Operation is complete,
Management station initiates the
close.
7 >--<CTL=FIN,ACK>------------------->
8 <--<CTL=ACK>-----------------------<
9 <--<CTL=FIN,ACK>-------------------<
10 >--<CTL=ACK>----------------------->
Wait 2 MSL
Connection now closed.
パケット経営者側はオープンな数の駅のオブジェクト接続を管理しました… 1>--<CTL=SYN>。----------------------->2<--<CTL=SYN、ACK>。-------------------<3>--<CTL=ACK>。-----------------------現在オープンな>接続、SNMP Requestを送ります。 4>--<データ=SNMPは>を要求します。------------->応答が来る、逆5<--<DATA=SNMP Response、CTL=ACK>。---<6>--<CTL=ACK>。----------------------->操作が完全である、Managementステーションは閉鎖を開始します。 7>--<CTLはフィン、ACK>と等しいです。------------------->8<--<CTL=ACK>。-----------------------<9<--<CTLはフィン、ACK>と等しいです。-------------------<10>--<CTL=ACK>。----------------------->待2ちMSL Connectionは今や、閉じました。
Some optimizations are possible IF the TCP has knowledge of the type of operation. However, a general purpose TCP would not be tuned to SNMP operations so those optimizations would not be done.
TCPに操作のタイプに関する知識があるなら、いくつかの最適化が可能です。 しかしながら、SNMP操作は汎用のTCPに調整されないでしょう、したがって、それらの最適化をしないでしょう。
10. References
10. 参照
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[1] SNMPが研究するケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、RFC1157、国際言語運用機構、国際言語運用機構(MITコンピュータサイエンス研究所)は1990がそうするかもしれません。
[2] Rose, M., Editor, "SNMP over OSI", RFC 1161, Performance Systems
International, Inc., June 1990.
[2] ローズ、M.、エディタ、「OSIの上のSNMP」、RFC1161、言語運用機構国際Inc.、6月1990日
[3] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
Laboratory for Computer Science, NYSERNet, Inc., University of
Tennessee at Knoxville, February 1989.
[3]SchoffstallとM.とデーヴィンとC.とヒョードル、M.とJ.ケース、「イーサネットの上のSNMP」RFC1089、レンセラー工科大学、MITコンピュータサイエンス研究所、NYSERNet Inc.、ノクスビル(1989年2月)のテネシー大学。
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[4] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[5] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年8月に設けるUSC/情報。
[6] Wormley, R., "SNMP Over IPX", draft in process, August 1990.
1990年8月のワァムリー、R.、「IPXの上のSNMP」がプロセスで作成する[6]。
SNMP Working Group [Page 10] RFC 1270 SNMP Communications Services October 1991
SNMPワーキンググループ[10ページ]RFC1270SNMP情報提供サービス1991年10月
[7] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1250,
IAB, August 1991.
[7] ポステル、J.、エディタ、「IABの公式のプロトコル標準」、RFC1250、IAB、1991年8月。
[8] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[8] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、NRI、1988年4月。
[9] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[9]ローズM.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1155、国際パフォーマンスSystemsヒューズLAN Systems(1990年5月)
[10] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[10]McCloghrie K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1156、ヒューズLAN Systems、国際パフォーマンスSystems、1990年5月。
11. Acknowledgements
11. 承認
The author wishes to thank Jeff Case, Chuck Davin and Keith McCloghrie for their technical and editorial contributions to this document.
作者はこのドキュメントへの彼らの技術的で編集の貢献についてジェフCase、チャック・デーヴィン、およびキースMcCloghrieに感謝したがっています。
12. Author's Address
12. 作者のアドレス
Frank Kastenholz Clearpoint Research Corporation 35 Parkwood Drive Hopkinton, Mass. 01748
フランクKastenholz Clearpoint研究社35のParkwood Driveホプキントン、マサチューセッツ州 01748
Phone: (508) 435-2000
以下に電話をしてください。 (508) 435-2000
Email: kasten@europa.clearpoint.com
メール: kasten@europa.clearpoint.com
SNMP Working Group [Page 11]
SNMP作業部会[11ページ]
一覧
スポンサーリンク
