RFC1449 日本語訳
1449 Transport Mappings for version 2 of the Simple Network ManagementProtocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=41161 bytes) (Obsoleted by RFC1906) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Case
Request for Comments: 1449 SNMP Research, Inc.
K. McCloghrie
Hughes LAN Systems
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
Carnegie Mellon University
April 1993
コメントを求めるワーキンググループJ.ケース要求をネットワークでつないでください: 1449台のSNMP研究Inc.K.McCloghrieヒューズLANシステムM.がドーヴァービーチコンサルティングInc.S.Waldbusserカーネギーメロン大学1993年4月に上昇しました。
Transport Mappings
for version 2 of the
Simple Network Management Protocol (SNMPv2)
Simple Network Managementプロトコルのバージョン2のための輸送Mappings(SNMPv2)
Status of this Memo
このMemoの状態
This RFC specifes an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"IAB Official Protocol Standards" for the standardization
state and status of this protocol. Distribution of this memo
is unlimited.
改良のためのIAB規格道がインターネットコミュニティのために議定書の中で述べるこのRFC specifes、要求議論、および提案。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 2
2 Definitions ........................................... 3
3 SNMPv2 over UDP ....................................... 7
3.1 Serialization ....................................... 7
3.2 Well-known Values ................................... 7
4 SNMPv2 over OSI ....................................... 8
4.1 Serialization ....................................... 8
4.2 Well-known Values ................................... 8
5 SNMPv2 over DDP ....................................... 9
5.1 Serialization ....................................... 9
5.2 Well-known Values ................................... 9
5.3 Discussion of AppleTalk Addressing .................. 9
5.3.1 How to Acquire NBP names .......................... 10
5.3.2 When to Turn NBP names into DDP addresses ......... 11
5.3.3 How to Turn NBP names into DDP addresses .......... 11
5.3.4 What if NBP is broken ............................. 12
6 SNMPv2 over IPX ....................................... 13
6.1 Serialization ....................................... 13
6.2 Well-known Values ................................... 13
7 Proxy to SNMPv1 ....................................... 14
7.1 Transport Domain: rfc1157Domain ..................... 14
7.2 Authentication Algorithm: rfc1157noAuth ............. 14
1つの序論… 2 1.1 用語に関する注… 2 2の定義… UDPの上の3 3SNMPv2… 7 3.1連載… 7 3.2 よく知られる値… OSIの上の7 4SNMPv2… 8 4.1連載… 8 4.2 よく知られる値… DDPの上の8 5SNMPv2… 9 5.1連載… 9 5.2 よく知られる値… 9 5.3 AppleTalkアドレシングの議論… 9 5.3 .1、Acquire NBP名へのどのように… 10 5.3 .2 DDPアドレスへのTurn NBP名に… 11 5.3 .3 Turn NBPへのどのようにがアドレスをDDPと命名するか… 11 5.3 .4 NBPが壊れていると、どうなるだろうか… 12 IPXの上の6SNMPv2… 13 6.1連載… 13 6.2 よく知られる値… 13 SNMPv1の7プロキシ… 14 7.1 ドメインを輸送してください: rfc1157ドメイン… 14 7.2認証アルゴリズム: rfc1157noAuth… 14
Case, McCloghrie, Rose & Waldbusser [Page i]
ケース、McCloghrie、ローズ、およびWaldbusser[ページi]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
8 Serialization using the Basic Encoding Rules .......... 16
8.1 Usage Example ....................................... 17
9 Acknowledgements ...................................... 18
10 References ........................................... 22
11 Security Considerations .............................. 24
12 Authors' Addresses ................................... 24
13 Security Considerations .............................. 25
14 Authors' Addresses ................................... 25
基本的なコード化を使用する8連載が統治されます… 16 8.1使用例… 17 9つの承認… 18 10の参照箇所… 22 11のセキュリティ問題… 24 12人の作者のアドレス… 24 13のセキュリティ問題… 25 14人の作者のアドレス… 25
Case, McCloghrie, Rose & Waldbusser [Page 1]
ケース、McCloghrie、ローズ、およびWaldbusser[1ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
1. Introduction
1. 序論
A network management system contains: several (potentially
many) nodes, each with a processing entity, termed an agent,
which has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines both authentication and
authorization policies.
ネットワーク管理システムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証と承認方針の両方を定義する管理フレームワークの下で行われます。
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to their
management information.
ネットワークマネージメントステーションはネットワーク要素をモニターして、制御する管理アプリケーションを作成します。 ネットワーク要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
The management protocol, version 2 of the Simple Network
Management Protocol [1], may be used over a variety of
protocol suites. It is the purpose of this document to define
how the SNMPv2 maps onto an initial set of transport domains.
Other mappings may be defined in the future.
管理プロトコル(Simple Network Managementプロトコル[1]のバージョン2)はさまざまなプロトコル群にわたって使用されるかもしれません。 SNMPv2がどう1人の始発の輸送にドメインを写像するかを定義するのは、このドキュメントの目的です。 他のマッピングは将来、定義されるかもしれません。
Although several mappings are defined, the mapping onto UDP is
the preferred mapping. As such, to provide for the greatest
level of interoperability, systems which choose to deploy
other mappings should also provide for proxy service to the
UDP mapping.
いくつかのマッピングが定義されますが、UDPへのマッピングは都合のよいマッピングです。 また、そういうものとして、最も大きいレベルの相互運用性に備えるために、他のマッピングを配布するのを選ぶシステムはUDPマッピングへの代理業務に備えるはずです。
1.1. A Note on Terminology
1.1. 用語に関する注
For the purpose of exposition, the original Internet-standard
Network Management Framework, as described in RFCs 1155, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2 framework
(SNMPv2).
博覧会の目的のために、RFCs1155、1157年、および1212年に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
Case, McCloghrie, Rose & Waldbusser [Page 2]
ケース、McCloghrie、ローズ、およびWaldbusser[2ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
2. Definitions
2. 定義
SNMPv2-TM DEFINITIONS ::= BEGIN
SNMPv2-Tm定義:、:= 始まってください。
IMPORTS
snmpDomains, snmpProxys
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
SNMPv2-Tcからの原文のコンベンションのSNMPv2-SMIからの輸入snmpDomains、snmpProxys。
-- SNMPv2 over UDP
-- UDPの上のSNMPv2
snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 }
-- for a SnmpUDPAddress of length 6:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order
--
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address."
SYNTAX OCTET STRING (SIZE (6))
snmpUDPDomainオブジェクト識別子:、:= 長さ6のSnmpUDPAddressのためのsnmpDomains1: -- -- 八重奏コンテンツコード化--1-4 ネットワークバイトオーダー--5-6 UDP-ポートネットワークバイトオーダー--IP-アドレスSnmpUDPAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d/2d"STATUSの現在の記述は「UDPアドレスを表します」。 構文八重奏ストリング(サイズ(6))
Case, McCloghrie, Rose & Waldbusser [Page 3]
ケース、McCloghrie、ローズ、およびWaldbusser[3ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
-- SNMPv2 over OSI
-- OSIの上のSNMPv2
snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 }
snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 }
-- for a SnmpOSIAddress of length m:
--
-- octets contents encoding
-- 1 length of NSAP "n" as an unsigned-integer
-- (either 0 or from 3 to 20)
-- 2..(n+1) NSAP concrete binary representation
-- (n+2)..m TSEL string of (up to 64) octets
--
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address."
SYNTAX OCTET STRING (SIZE (1 | 4..85))
snmpCLNSDomainオブジェクト識別子:、:= snmpDomains2snmpCONSDomainオブジェクト識別子:、:= 長さのmのSnmpOSIAddressのためのsnmpDomains3: -- -- 八重奏コンテンツコード化--符号のない整数としてのNSAP「n」の1つの長さ--(3〜どちらかの0か20)--2。(n+1) NSAPの具体的な2進法表示--(n+2。)TSELが結ぶ(最大64)八重奏のm--、SnmpOSIAddress:、:= 「原文のコンベンションは」 *1x: /1xをディスプレイでほのめかします」 STATUSの現在の記述は「OSI輸送アドレスを表します」。 構文八重奏ストリング(サイズ(1| 4 .85))
Case, McCloghrie, Rose & Waldbusser [Page 4]
ケース、McCloghrie、ローズ、およびWaldbusser[4ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
-- SNMPv2 over DDP
-- DDPの上のSNMPv2
snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 }
-- for a SnmpNBPAddress of length m:
--
-- octets contents encoding
-- 1 length of object "n" as an unsigned integer
-- 2..(n+1) object string of (up to 32) octets
-- n+2 length of type "p" as an unsigned integer
-- (n+3)..(n+2+p) type string of (up to 32) octets
-- n+3+p length of zone "q" as an unsigned integer
-- (n+4+p)..m zone string of (up to 32) octets
--
-- for comparison purposes, strings are case-insensitive
--
-- all strings may contain any octet other than 255 (hex ff)
--
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name."
SYNTAX OCTET STRING (SIZE (3..99))
snmpDDPDomainオブジェクト識別子:、:= 長さのmのSnmpNBPAddressのためのsnmpDomains4: -- -- 2をコード化する(符号のない整数としての1つの長さのオブジェクト「n」)八重奏コンテンツ。(n+1) (最大32)八重奏のオブジェクトストリング--符号のない整数としてのタイプ「p」のn+2長さ--(n+3。)(n+2+p) (最大32)八重奏(符号のない整数としてのゾーン「q」のn+3+pの長さ)のストリング(n+4+p)をタイプしてください。(最大32)八重奏の----比較目的のために、ストリングが大文字と小文字を区別しない--mゾーンストリング--すべてのストリングが255(十六進法ff)以外のどんな八重奏も含むかもしれません--、SnmpNBPAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「NBP名を表します」。 構文八重奏ストリング(サイズ(3 .99))
-- SNMPv2 over IPX
-- IPXの上のSNMPv2
snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 }
-- for a SnmpIPXAddress of length 12:
--
-- octets contents encoding
-- 1-4 network-number network-byte order
-- 5-10 physical-address network-byte order
-- 11-12 socket-number network-byte order
--
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address."
SYNTAX OCTET STRING (SIZE (12))
snmpIPXDomainオブジェクト識別子:、:= 長さ12のSnmpIPXAddressのためのsnmpDomains5: -- -- コード化--1-4 ネットワーク・ナンバーネットワークバイトオーダー--5-10 物理アドレスネットワークバイトオーダー--11-12 ソケット番号ネットワークバイトオーダー--八重奏コンテンツSnmpIPXAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「4x.1x:1x:1x:1x:1x: 1x.2d」STATUSの現在の記述は「IPXアドレスを表します」。 構文八重奏ストリング(サイズ(12))
Case, McCloghrie, Rose & Waldbusser [Page 5]
ケース、McCloghrie、ローズ、およびWaldbusser[5ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
-- for proxy to community-based SNMPv1 (RFC 1157)
-- 地域密着型のSNMPv1のプロキシのために(RFC1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Proxyオブジェクト識別子:、:= snmpProxys1
-- uses SnmpUDPAddress
rfc1157Domain OBJECT IDENTIFIER ::= { rfc1157Proxy 1 }
-- 用途SnmpUDPAddress rfc1157Domain OBJECT IDENTIFIER:、:= rfc1157Proxy1
-- the community-based noAuth
rfc1157noAuth OBJECT IDENTIFIER ::= { rfc1157Proxy 2 }
-- 地域密着型のnoAuth rfc1157noAuth OBJECT IDENTIFIER:、:= rfc1157Proxy2
END
終わり
Case, McCloghrie, Rose & Waldbusser [Page 6]
ケース、McCloghrie、ローズ、およびWaldbusser[6ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
3. SNMPv2 over UDP
3. UDPの上のSNMPv2
This is the preferred transport mapping.
これは都合のよい輸送マッピングです。
3.1. Serialization
3.1. 連載
Each instance of a message is serialized onto a single UDP[2]
datagram, using the algorithm specified in Section 8.
セクション8で指定されたアルゴリズムを使用して、メッセージの各インスタンスは単一のUDP[2]データグラムに連載されます。
3.2. Well-known Values
3.2. よく知られる値
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on UDP port 161. Further, it is suggested that
notification sinks be configured to listen on UDP port 162.
partyTableはSNMPv2パーティーのために輸送アドレス指定情報を与えますが、管理者がUDPポート161の上で聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案されます。 さらに、通知流し台がUDPポート162の上で聴くために構成されることが提案されます。
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
また、partyTableはSNMPv2パーティーが受け入れても構わないと思っている最大のメッセージサイズを記載します。 この値は少なくとも484の八重奏でなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。
Case, McCloghrie, Rose & Waldbusser [Page 7]
ケース、McCloghrie、ローズ、およびWaldbusser[7ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
4. SNMPv2 over OSI
4. OSIの上のSNMPv2
This is an optional transport mapping.
これは任意の輸送マッピングです。
4.1. Serialization
4.1. 連載
Each instance of a message is serialized onto a single TSDU
[3,4] for the OSI Connectionless-mode Transport Service
(CLTS), using the algorithm specified in Section 8.
メッセージの各インスタンスはOSI Connectionless-モードTransport Service(CLTS)のために独身のTSDU[3、4]に連載されます、セクション8で指定されたアルゴリズムを使用して。
4.2. Well-known Values
4.2. よく知られる値
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on transport selector "snmp-l" (which consists of six
ASCII characters), when using a CL-mode network service to
realize the CLTS. Further, it is suggested that notification
sinks be configured to listen on transport selector "snmpt-l"
(which consists of seven ASCII characters) when using a CL-
mode network service to realize the CLTS. Similarly, when
using a CO-mode network service to realize the CLTS, the
suggested transport selectors are "snmp-o" and "snmpt-o", for
agent and notification sink, respectively.
partyTableはSNMPv2パーティーのために輸送アドレス指定情報を与えますが、管理者がCLTSがわかるのにCL-モードネットワーク・サービスを使用するとき輸送セレクタの上に「snmp-l」(6人のASCII文字から成る)を聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案されます。 さらに、通知流し台がCLTSがわかるのにCLモードネットワーク・サービスを使用するとき、輸送セレクタの上に「snmpt-l」(7人のASCII文字から成る)を聴くために構成されることが提案されます。 CLTSがわかるのにCO-モードネットワーク・サービスを使用するとき、同様に、提案された輸送セレクタは、"snmp-o"と"snmpt-o"です、エージェントと通知がそれぞれ沈むので。
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
また、partyTableはSNMPv2パーティーが受け入れても構わないと思っている最大のメッセージサイズを記載します。 この値は少なくとも484の八重奏でなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。
Case, McCloghrie, Rose & Waldbusser [Page 8]
ケース、McCloghrie、ローズ、およびWaldbusser[8ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
5. SNMPv2 over DDP
5. DDPの上のSNMPv2
This is an optional transport mapping.
これは任意の輸送マッピングです。
5.1. Serialization
5.1. 連載
Each instance of a message is serialized onto a single DDP
datagram [5], using the algorithm specified in Section 8.
セクション8で指定されたアルゴリズムを使用して、メッセージの各インスタンスは単一のDDPデータグラム[5]に連載されます。
5.2. Well-known Values
5.2. よく知られる値
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2
entities acting in an agent role listens on DDP socket number
8, whilst notification sinks listen on DDP socket number 9.
SNMPv2メッセージにDDPプロトコルタイプ8を使用させます。 エージェントの役割におけるSNMPv2実体芝居はDDPソケットNo.8で聴かれます、通知流し台がDDPソケットNo.9で聴かれますが。
Although the partyTable gives transport addressing information
for an SNMPv2 party, administrators must configure their
SNMPv2 entities acting in an agent role to use NBP type "SNMP
Agent" (which consists of ten ASCII characters), whilst
notification sinks must be configured to use NBP type "SNMP
Trap Handler" (which consists of seventeen ASCII characters).
partyTableはSNMPv2パーティーのために輸送アドレス指定情報を与えますが、管理者は、NBPを使用するためにエージェントの役割で行動する彼らのSNMPv2実体が「SNMPエージェント」(10人のASCII文字から成る)をタイプするのを構成しなければなりません、NBPタイプ「SNMP罠操作者」(17人のASCII文字から成る)を使用するために通知流し台を構成しなければなりませんが。
The NBP name for agents and notification sinks should be
stable - NBP names should not change any more often than the
IP address of a typical TCP/IP node. It is suggested that the
NBP name be stored in some form of stable storage.
エージェントと通知流し台のためのNBP名は安定しているべきです--NBP名はもう典型的なTCP/IPノードのIPアドレスよりしばしば変化するべきであるというわけではありません。 NBP名が何らかの形式の安定貯蔵に保存されることが提案されます。
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
また、partyTableはSNMPv2パーティーが受け入れても構わないと思っている最大のメッセージサイズを記載します。 この値は少なくとも484の八重奏でなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。
5.3. Discussion of AppleTalk Addressing
5.3. AppleTalkアドレシングの議論
The AppleTalk protocol suite has certain features not manifest
in the TCP/IP suite. AppleTalk's naming strategy and the
dynamic nature of address assignment can cause problems for
SNMPv2 entities that wish to manage AppleTalk networks.
TCP/IP nodes have an associated IP address which distinguishes
each from the other. In contrast, AppleTalk nodes generally
have no such characteristic. The network-level address, while
often relatively stable, can change at every reboot (or more
AppleTalkプロトコル群で、ある特徴はTCP/IPスイートで現れるようになりません。 AppleTalkが戦略とアドレスのダイナミックな本質を課題と命名すると、AppleTalkネットワークを管理するというその願望はSNMPv2実体のための問題に引き起こされる場合があります。 TCP/IPノードには、もう片方とそれぞれを区別する関連IPアドレスがあります。 対照的に、一般に、AppleTalkノードには、どんなそのような特性もありません。 ネットワークレベルアドレスがあらゆるリブートのときにしばしば比較的安定している間、変化できる、(以上
Case, McCloghrie, Rose & Waldbusser [Page 9]
ケース、McCloghrie、ローズ、およびWaldbusser[9ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
frequently).
頻繁に)
Thus, when SNMPv2 is mapped over DDP, nodes are identified by
a "name", rather than by an "address". Hence, all AppleTalk
nodes that implement this mapping are required to respond to
NBP lookups and confirms (e.g., implement the NBP protocol
stub), which guarantees that a mapping from NBP name to DDP
address will be possible.
SNMPv2がDDPの上で写像されるとき、したがって、ノードは「アドレス」でというよりむしろ「名前」によって特定されます。 したがって、このマッピングを実装するすべてのAppleTalkノードが、NBPルックアップに応じるのが必要であり、どれが、NBP名からDDPアドレスまでのマッピングが可能になるのを保証するかと確認します(例えば、NBPプロトコルスタッブを実装します)。
In determining the SNMP identity to register for an SNMPv2
entity, it is suggested that the SNMP identity be a name which
is associated with other network services offered by the
machine.
SNMPのアイデンティティがSNMPv2実体に登録することを決定する際に、SNMPのアイデンティティがマシンで提供する他のネットワーク・サービスに関連している名前であると示唆されます。
NBP lookups, which are used to map NBP names into DDP
addresses, can cause large amounts of network traffic as well
as consume CPU resources. It is also the case that the
ability to perform an NBP lookup is sensitive to certain
network disruptions (such as zone table inconsistencies) which
would not prevent direct AppleTalk communications between two
SNMPv2 entities.
NBPルックアップ(NBP名をDDPアドレスに写像するのに使用される)は、多量のネットワークトラフィックを引き起こして、CPUリソースを消費できます。 また、NBPルックアップを実行する能力が2つのSNMPv2実体のダイレクトAppleTalkコミュニケーションを防がない、あるネットワーク分裂(ゾーンテーブル矛盾などの)に敏感であることは、事実です。
Thus, it is recommended that NBP lookups be used infrequently,
primarily to create a cache of name-to-address mappings.
These cached mappings should then be used for any further SNMP
traffic. It is recommended that SNMPv2 entities acting in a
manager role should maintain this cache between reboots. This
caching can help minimize network traffic, reduce CPU load on
the network, and allow for (some amount of) network trouble
shooting when the basic name-to-address translation mechanism
is broken.
したがって、NBPルックアップが主として名前からアドレス・マッピングのキャッシュを作成するのにまれに使用されるのは、お勧めです。 そして、これらのキャッシュされたマッピングはどんなさらなるSNMPトラフィックにも使用されるべきです。 マネージャの役割で行動するSNMPv2実体がリブートの間のこのキャッシュを維持するのは、お勧めです。 このキャッシュが、ネットワークトラフィックを最小にするのを助けることができて、ネットワークでCPU荷重を抑えてください、許容、(或るものが達する、)、名前からアドレス変換への基本的なメカニズムが壊れているときにはトラブルシューティングをネットワークでつないでください。
5.3.1. How to Acquire NBP names
5.3.1. Acquire NBP名へのどのように
An SNMPv2 entity acting in a manager role may have a pre-
configured list of names of "known" SNMPv2 entities acting in
an agent role. Similarly, an SNMPv2 entity acting in a
manager role might interact with an operator. Finally, an
SNMPv2 entity acting in a manager role might communicate with
all SNMPv2 entities acting in an agent role in a set of zones
or networks.
マネージャの役割で行動するSNMPv2実体で、「知られている」SNMPv2実体のあらかじめ構成された名簿はエージェントの役割で行動するかもしれません。 同様に、マネージャの役割で行動するSNMPv2実体はオペレータと対話するかもしれません。 最終的に、マネージャの役割で行動するSNMPv2実体は1セットのゾーンかネットワークにおけるエージェントの役割で行動するすべてのSNMPv2実体で交信するかもしれません。
Case, McCloghrie, Rose & Waldbusser [Page 10]
ケース、McCloghrie、ローズ、およびWaldbusser[10ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
5.3.2. When to Turn NBP names into DDP addresses
5.3.2. DDPアドレスへのTurn NBP名へのいつ
When an SNMPv2 entity uses a cache entry to address an SNMP
packet, it should attempt to confirm the validity mapping, if
the mapping hasn't been confirmed within the last T1 seconds.
This cache entry lifetime, T1, has a minimum, default value of
60 seconds, and should be configurable.
SNMPv2実体がSNMPパケットを扱うのにキャッシュエントリーを使用すると、正当性マッピングを確認するのを試みるべきです、マッピングが最後のT1秒以内に確認されていないなら。 これは、エントリー生涯、T1をキャッシュして、最小限、60秒のデフォルト値を持って、構成可能であるべきです。
An SNMPv2 entity acting in a manager role may decide to prime
its cache of names prior to actually communicating with
another SNMPv2 entity. In general, it is expected that such
an entity may want to keep certain mappings "more current"
than other mappings, e.g., those nodes which represent the
network infrastructure (e.g., routers) may be deemed "more
important".
マネージャの役割で行動するSNMPv2実体は、実際に別のSNMPv2実体で交信する前に名前のキャッシュを用意すると決めるかもしれません。 一般に、そのような実体が「他のマッピングより現在」に、あるマッピングを保ちたがっているかもしれないと予想されて、例えば、ネットワークインフラ(例えば、ルータ)を表すそれらのノードは「より重要である」と考えられるかもしれません。
Note that an SNMPv2 entity acting in a manager role should not
prime its entire cache upon initialization - rather, it should
attempt resolutions over an extended period of time (perhaps
in some pre-determined or configured priority order). Each of
these resolutions might, in fact, be a wildcard lookup in a
given zone.
マネージャの役割で行動するSNMPv2実体が初期化のときに全体のキャッシュを用意するべきでないことに注意してください--むしろ、それは時間(恐らく何らかの予定されたか構成された優先順による)の長期間の間、解決を試みるべきです。 事実上、それぞれのこれらの解決は与えられたゾーンのワイルドカードルックアップであるかもしれません。
An SNMPv2 entity acting in an agent role must never prime its
cache. Such an entity should do NBP lookups (or confirms)
only when it needs to send an SNMP trap. When generating a
response, such an entity does not need to confirm a cache
entry.
エージェントの役割で行動するSNMPv2実体はキャッシュを決して用意してはいけません。 そのような実体がNBPにルックアップをするべきである、(確認、)、SNMP罠を送る必要がある場合にだけ。 応答を生成するとき、そのような実体はキャッシュエントリーを確認する必要はありません。
5.3.3. How to Turn NBP names into DDP addresses
5.3.3. DDPアドレスへのTurn NBP名へのどのように
If the only piece of information available is the NBP name,
then an NBP lookup should be performed to turn that name into
a DDP address. However, if there is a piece of stale
information, it can be used as a hint to perform an NBP
confirm (which sends a unicast to the network address which is
presumed to be the target of the name lookup) to see if the
stale information is, in fact, still valid.
唯一の利用可能な情報がNBP名であるなら、NBPルックアップは、その名前をDDPアドレスに変えるために実行されるべきです。 しかしながら、1つの聞き古した情報があれば、NBPを実行するのにヒントとしてそれを使用できる、確認、(あえてルックアップという名前の目標であるネットワーク・アドレスにユニキャストを送ります) 事実上、聞き古した情報がまだ有効であるかどうか確認するために。
An NBP name to DDP address mapping can also be confirmed
implicitly using only SNMP transactions. For example, an
SNMPv2 entity acting in a manager role issuing a retrieval
operation could also retrieve the relevant objects from the
NBP group [6] for the SNMPv2 entity acting in an agent role.
また、それとなくSNMPトランザクションだけを使用することでDDPアドレス・マッピングへのNBP名を確認できます。 例えば、また、検索操作を発行するマネージャの役割で行動するSNMPv2実体はエージェントの役割で行動するSNMPv2実体のためにNBPグループ[6]から関連オブジェクトを検索するかもしれません。
Case, McCloghrie, Rose & Waldbusser [Page 11]
ケース、McCloghrie、ローズ、およびWaldbusser[11ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
This information can then be correlated with the source DDP
address of the response.
そして、この情報は応答のソースDDPアドレスで関連できます。
5.3.4. What if NBP is broken
5.3.4. NBPが壊れていると、どうなるでしょうか?
Under some circumstances, there may be connectivity between
two SNMPv2 entities, but the NBP mapping machinery may be
broken, e.g.,
いくつかの状況で、2つのSNMPv2実体の間には、接続性があるかもしれませんが、機械を写像するNBPは例えば壊れているかもしれません。
o the NBP FwdReq (forward NBP lookup onto local attached
network) mechanism might be broken at a router on the
other entity's network; or,
o NBP FwdReq(ローカルの付属ネットワークへの前進のNBPルックアップ)メカニズムはもう片方の実体のネットワークでルータで壊れているかもしれません。 または
o the NBP BrRq (NBP broadcast request) mechanism might be
broken at a router on the entity's own network; or,
o NBP BrRq(NBP放送要求)メカニズムは実体の自身のネットワークでルータで壊れているかもしれません。 または
o NBP might be broken on the other entity's node.
o NBPはもう片方の実体のノードで壊れているかもしれません。
An SNMPv2 entity acting in a manager role which is dedicated
to AppleTalk management might choose to alleviate some of
these failures by directly implementing the router portion of
NBP. For example, such an entity might already know all the
zones on the AppleTalk internet and the networks on which each
zone appears. Given an NBP lookup which fails, the entity
could send an NBP FwdReq to the network in which the agent was
last located. If that failed, the station could then send an
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to
each network number on that network. Of the above (single)
failures, this combined approach will solve the case where
either the local router's BrRq-to-FwdReq mechanism is broken
or the remote router's FwdReq-to-LkUp mechanism is broken.
AppleTalk管理に捧げられるマネージャの役割で行動するSNMPv2実体は、直接NBPのルータ一部を実装することによってこれらの失敗のいくつかを軽減するのを選ぶかもしれません。 例えば、そのような実体は既に、AppleTalkインターネットのすべてのゾーンと各ゾーンが現れるネットワークを知るかもしれません。 失敗するNBPルックアップを考えて、実体はエージェントが最後に位置したネットワークにNBP FwdReqを送るかもしれません。 それが失敗するなら、ステーションは指示された(DDP)マルチキャストとしてNBP LkUp(NBPルックアップパケット)をそのネットワークの各ネットワーク・ナンバーに送ることができるでしょうに。 上(単一の)の失敗では、この結合したアプローチはBrRqからFwdReqへのローカルルータのメカニズムが壊れているか、またはFwdReqからLkUpへのリモートルータのメカニズムが壊れているケースを解決するでしょう。
Case, McCloghrie, Rose & Waldbusser [Page 12]
ケース、McCloghrie、ローズ、およびWaldbusser[12ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
6. SNMPv2 over IPX
6. IPXの上のSNMPv2
This is an optional transport mapping.
これは任意の輸送マッピングです。
6.1. Serialization
6.1. 連載
Each instance of a message is serialized onto a single IPX
datagram [7], using the algorithm specified in Section 8.
セクション8で指定されたアルゴリズムを使用して、メッセージの各インスタンスは単一のIPXデータグラム[7]に連載されます。
6.2. Well-known Values
6.2. よく知られる値
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
Exchange Packet).
SNMPv2メッセージにIPXパケットタイプ4(すなわち、Packet Exchange Packet)を使用させます。
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on IPX socket 36879 (900f hexadecimal). Further, it is
suggested that notification sinks be configured to listen on
IPX socket 36880 (9010 hexadecimal)
partyTableがSNMPv2パーティーのために輸送アドレス指定情報を与えますが、管理者がIPXソケット36879の上に聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案される、(900f、16進) さらに、通知流し台がIPXソケット36880の上に聴くために構成されることが提案されます。(9010 16進)
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 546 octets. Implementation of larger values is
encouraged whenever possible.
また、partyTableはSNMPv2パーティーが受け入れても構わないと思っている最大のメッセージサイズを記載します。 この値は少なくとも546の八重奏でなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。
Case, McCloghrie, Rose & Waldbusser [Page 13]
ケース、McCloghrie、ローズ、およびWaldbusser[13ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
7. Proxy to SNMPv1
7. SNMPv1のプロキシ
In order to provide proxy to community-based SNMP [8], some
definitions are necessary for both transport domains and
authentication protocols.
地域密着型のSNMP[8]にプロキシを供給するために、いくつかの定義が輸送ドメインと認証プロトコルの両方に必要です。
7.1. Transport Domain: rfc1157Domain
7.1. ドメインを輸送してください: rfc1157Domain
The transport domain, rfc1157Domain, indicates the transport
mapping for community-based SNMP messages defined in RFC 1157.
When a party's transport domain (partyTDomain) is
rfc1157Domain:
輸送ドメイン(rfc1157Domain)は地域密着型のSNMPのためにRFC1157で定義されたメッセージを写像する輸送を示します。 パーティーの輸送ドメイン(partyTDomain)がrfc1157Domainであるときに:
(1) the party's transport address (partyTAddress) shall be 6
octets long, the initial 4 octets containing the IP-
address in network-byte order, and the last two octets
containing the UDP port in network-byte order; and,
(1) パーティーの輸送アドレス(partyTAddress)は長い間、6つの八重奏になるでしょう、初期の4つの八重奏はネットワークバイトオーダーにIPアドレスを含んでいて、ネットワークバイトオーダーにUDPポートを含む最後の2つの八重奏を含んでいて。 そして
(2) the party's authentication protocol (partyAuthProtocol)
shall be rfc1157noAuth.
(2) パーティーの認証プロトコル(partyAuthProtocol)はrfc1157noAuthになるでしょう。
When a proxy relationship identifies a proxy destination party
which has rfc1157Domain as its transport domain:
プロキシ関係が輸送ドメインとしてrfc1157Domainを持っているプロキシ目的地パーティーを特定するとき:
(1) the proxy source party (contextSrcPartyIndex) and proxy
context (contextProxyContext) components of the proxy
relationship are irrelevant; and,
(1) プロキシ関係のプロキシソースパーティー(contextSrcPartyIndex)とプロキシ文脈(contextProxyContext)コンポーネントは無関係です。 そして
(2) Section 3.1 of [9] specifies the behavior of the proxy
agent.
(2) [9]のセクション3.1はプロキシエージェントの振舞いを指定します。
7.2. Authentication Algorithm: rfc1157noAuth
7.2. 認証アルゴリズム: rfc1157noAuth
A party's authentication protocol (partyAuthProtocol)
specifies the protocol and mechanism by which the party
authenticates the integrity and origin of the SNMPv1 or SNMPv2
PDUs it generates. When a party's authentication protocol is
rfc1157noAuth:
パーティーの認証プロトコル(partyAuthProtocol)はパーティーがそれが生成するSNMPv1かSNMPv2 PDUsの保全と発生源を認証するプロトコルとメカニズムを指定します。 パーティーの認証プロトコルがrfc1157noAuthであるときに:
(1) the party's public authentication key (partyAuthPublic),
clock (partyAuthClock), and lifetime (partyAuthLifetime)
are irrelevant; and,
(1) パーティーの公共の認証キー(partyAuthPublic)、時計(partyAuthClock)、および寿命(partyAuthLifetime)は無関係です。 そして
Case, McCloghrie, Rose & Waldbusser [Page 14]
ケース、McCloghrie、ローズ、およびWaldbusser[14ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
(2) the party's private authentication key
(partySecretsAuthPrivate) shall be used as the 1157
community for the proxy destination, and shall be at
least one octet in length. (No maximum length is
specified.)
(2) パーティーの個人的な認証キー(partySecretsAuthPrivate)は、プロキシの目的地に1157年の共同体として使用されて、長さで少なくとも1つの八重奏になるでしょう。 (どんな最大の長さも指定されません。)
Note that when setting the party's private authentication key,
the exclusive-OR semantics specified in [10] still apply.
パーティーの個人的な認証キーを設定するとき、排他的論理和意味論が[10]で指定したことに注意してください、そして、それでも、申し込んでください。
Case, McCloghrie, Rose & Waldbusser [Page 15]
ケース、McCloghrie、ローズ、およびWaldbusser[15ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
8. Serialization using the Basic Encoding Rules
8. 基本的な符号化規則を使用する連載
When the Basic Encoding Rules [11] are used for serialization:
Basic Encoding Rules[11]が連載に使用されるとき:
(1) When encoding the length field, only the definite form is
used; use of the indefinite form encoding is prohibited.
Note that when using the definite-long form, it is
permissible to use more than the minimum number of length
octets necessary to encode the length field.
(1) 長さの分野をコード化するとき、已然形だけが使用されています。 無期フォームコード化の使用は禁止されています。 明確に長いフォームを使用するとき、長さの分野をコード化するのに必要な長さの八重奏の最小の数以上を使用するのが許されていることに注意してください。
(2) When encoding the value field, the primitive form shall
be used for all simple types, i.e., INTEGER, OCTET
STRING, OBJECT IDENTIFIER, and BIT STRING (either
IMPLICIT or explicit). The constructed form of encoding
shall be used only for structured types, i.e., a SEQUENCE
or an IMPLICIT SEQUENCE.
(2) 値の分野をコード化するとき、原始のフォームはすべての純真なタイプ、すなわち、INTEGER、OCTET STRING、OBJECT IDENTIFIER、およびBIT STRING(IMPLICITの、または、明白な)に使用されるものとします。 組み立てられたフォームのコード化は、すなわち、構造化されたタイプ、SEQUENCEだけにおいて使用されていてIMPLICIT SEQUENCEになるでしょう。
(3) When a BIT STRING is serialized, all named-bits are
transferred regardless of their truth-value. Further, if
the number of named-bits is not an integral multiple of
eight, then the fewest number of additional zero-valued
bits are transferred so that an integral multiple of
eight bits is transferred.
(3) BIT STRINGを連載するとき、それらの真理値にかかわらずすべての命名されたビットを移します。 さらに、最も数数の追加無評価されたビットが命名されたビットの数が8の不可欠の倍数でないならわたっているので、8ビットの不可欠の倍数はわたっています。
These restrictions apply to all aspects of ASN.1 encoding,
including the message wrappers, protocol data units, and the
data objects they contain.
これらの制限はASN.1コード化の全面に適用されます、メッセージラッパー、プロトコルデータ単位、およびそれらが含むデータ・オブジェクトを含んでいて。
Case, McCloghrie, Rose & Waldbusser [Page 16]
ケース、McCloghrie、ローズ、およびWaldbusser[16ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
8.1. Usage Example
8.1. 使用例
As an example of applying the Basic Encoding Rules, suppose
one wanted to encode an instance of the GetBulkRequest-PDU
[1]:
Basic Encoding Rulesを適用する例として、1つがGetBulkRequest-PDU[1]のインスタンスをコード化したがっていたと仮定してください:
[5] IMPLICIT SEQUENCE {
request-id 1414684022,
non-repeaters 1,
max-repetitions 2,
variable-bindings {
{ name sysUpTime,
value { unspecified NULL } },
{ name ipNetToMediaPhysAddress,
value { unspecified NULL } },
{ name ipNetToMediaType,
value { unspecified NULL } }
}
}
[5] 暗黙の系列要求イド1414684022、非リピータ1、最大反復2、変項束縛はsysUpTime、値の不特定のNULLを命名して、ipNetToMediaPhysAddress、値の不特定のNULLを命名して、ipNetToMediaType、値の不特定のNULLを命名します。
Applying the BER, this would be encoded (in hexadecimal) as:
BERを適用して、これは以下としてコード化されるでしょう(16進で)。
[5] IMPLICIT SEQUENCE a5 82 00 39
INTEGER 02 04 52 54 5d 76
INTEGER 02 01 01
INTEGER 02 01 02
SEQUENCE 30 2b
SEQUENCE 30 0b
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00
SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00
SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00
[5] IMPLICIT SEQUENCE a5 82 00 39INTEGER02 04 52 54 5d76INTEGER02 01 01INTEGER02 01 02SEQUENCE30 2b SEQUENCE30 0b OBJECT IDENTIFIER06 07 2b06 01 02 01 01 03NULL05 00SEQUENCE30 0d OBJECT IDENTIFIER06 09 2b06 01 02 01 04 16 01 02NULL05 00SEQUENCE30 0d OBJECT IDENTIFIER06 09 2b06 01 02 01 04 16 01 04NULL05 00
Note that the initial SEQUENCE is not encoded using the
minimum number of length octets. (The first octet of the
length, 82, indicates that the length of the content is
encoded in the next two octets.)
初期のSEQUENCEが長さの八重奏の最小の数を使用することでコード化されないことに注意してください。 (長さの最初の八重奏(82)は、内容の長さが次の2つの八重奏でコード化されるのを示します。)
Case, McCloghrie, Rose & Waldbusser [Page 17]
ケース、McCloghrie、ローズ、およびWaldbusser[17ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
9. Acknowledgements
9. 承認
The UDP-based mapping is based, in part, on RFC 1157.
UDPベースのマッピングはRFC1157に一部基づいています。
The OSI-based mapping is based, in part, on RFC 1283.
OSIベースのマッピングはRFC1283に一部基づいています。
The DDP-based mapping is based, in part, on earlier work by
Greg Minshall of Novell, Inc., and Mike Ritter of Apple
Computer, Inc.
DDPベースのマッピングはノベルInc.のグレッグMinshall、およびアップル・コンピューターInc.のマイク・リッターによる以前の仕事に一部基づいています。
The IPX-based mapping is based, in part, on RFC 1298.
IPXベースのマッピングはRFC1298に一部基づいています。
The section on proxy to community-based SNMP is based on
earlier work that was based in part on a suggestion by
Jonathan Biggar of Netlabs, Inc.
地域密着型のSNMPのプロキシの上のセクションはNetlabs Inc.のジョナサン・ビッガーによる提案に一部基づいた以前の仕事に基づいています。
Finally, the comments of the SNMP version 2 working group are
gratefully acknowledged:
最終的に、SNMPバージョン2ワーキンググループのコメントは感謝して承諾されます:
Beth Adams, Network Management Forum
Steve Alexander, INTERACTIVE Systems Corporation
David Arneson, Cabletron Systems
Toshiya Asaba
Fred Baker, ACC
Jim Barnes, Xylogics, Inc.
Brian Bataille
Andy Bierman, SynOptics Communications, Inc.
Uri Blumenthal, IBM Corporation
Fred Bohle, Interlink
Jack Brown
Theodore Brunner, Bellcore
Stephen F. Bush, GE Information Services
Jeffrey D. Case, University of Tennessee, Knoxville
John Chang, IBM Corporation
Szusin Chen, Sun Microsystems
Robert Ching
Chris Chiotasso, Ungermann-Bass
Bobby A. Clay, NASA/Boeing
John Cooke, Chipcom
Tracy Cox, Bellcore
Juan Cruz, Datability, Inc.
David Cullerot, Cabletron Systems
Cathy Cunningham, Microcom
James R. (Chuck) Davin, Bellcore
Michael Davis, Clearpoint
ベス・アダムス、ネットワークマネージメントフォーラムスティーブ・アレクサンダー、インタラクティブシステム社のデヴィッドArneson、CabletronシステムToshiya浅羽フレッド・ベイカー、ACCジム・バーンズ、Xylogics Inc.ブライアンBatailleアンディBierman、SynOpticsコミュニケーションInc.ユリ・ブルーメンソル(IBM社のフレッドBohle)はジャック・ブラウン・セオドア・ブルンナーを連結します、Bellcoreのスティーブン・F.ブッシュ、GE情報サービスジェフリーD; ケース、テネシー、ノクスビルジョン・チャンの大学、IBMの社のSzusinチェン、サン・マイクロシステムズロバートチンクリスChiotasso、アンガマン-バス巡査A.粘土、NASA/ボーイングのジョン・クック、Chipcomトレーシーはコックスを務めます、Bellcoreのホアン・クルーズ、Datability Inc.デヴィッドCullerot、Cabletronシステムキャシーカニンハム、Microcomジェームス・R.(チャック)デーヴィン、BellcoreのMichael Davis、Clearpoint
Case, McCloghrie, Rose & Waldbusser [Page 18]
ケース、McCloghrie、ローズ、およびWaldbusser[18ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
Mike Davison, FiberCom
Cynthia DellaTorre, MITRE
Taso N. Devetzis, Bellcore
Manual Diaz, DAVID Systems, Inc.
Jon Dreyer, Sun Microsystems
David Engel, Optical Data Systems
Mike Erlinger, Lexcel
Roger Fajman, NIH
Daniel Fauvarque, Sun Microsystems
Karen Frisa, CMU
Shari Galitzer, MITRE
Shawn Gallagher, Digital Equipment Corporation
Richard Graveman, Bellcore
Maria Greene, Xyplex, Inc.
Michel Guittet, Apple
Robert Gutierrez, NASA
Bill Hagerty, Cabletron Systems
Gary W. Haney, Martin Marietta Energy Systems
Patrick Hanil, Nokia Telecommunications
Matt Hecht, SNMP Research, Inc.
Edward A. Heiner, Jr., Synernetics Inc.
Susan E. Hicks, Martin Marietta Energy Systems
Geral Holzhauer, Apple
John Hopprich, DAVID Systems, Inc.
Jeff Hughes, Hewlett-Packard
Robin Iddon, Axon Networks, Inc.
David Itusak
Kevin M. Jackson, Concord Communications, Inc.
Ole J. Jacobsen, Interop Company
Ronald Jacoby, Silicon Graphics, Inc.
Satish Joshi, SynOptics Communications, Inc.
Frank Kastenholz, FTP Software
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Zbiginew Kielczewski, Eicon
Jongyeoi Kim
Andrew Knutsen, The Santa Cruz Operation
Michael L. Kornegay, VisiSoft
Deirdre C. Kostik, Bellcore
Cheryl Krupczak, Georgia Tech
Mark S. Lewis, Telebit
David Lin
David Lindemulder, AT&T/NCR
Ben Lisowski, Sprint
David Liu, Bell-Northern Research
マイク・デイヴィソン、FiberComシンシアDellaTorre(斜め継ぎTaso N.Devetzis、Bellcoreの手動のディアーズデヴィッドSystems Inc.ジョン・ドレイヤー、サン・マイクロシステムズのデヴィッド・エンゲル、光学データ・システムマイクErlinger、LexcelロジャーFajman、NIHダニエルFauvarque、サン・マイクロシステムズカレンFrisa、米カーネギーメロン大学Shari Galitzer、斜め継ぎショーン・ギャラガー、DECリチャードGraveman、Bellcoreのマリア・グリーン、Xyplex Inc.ミシェルGuittet、アップルのロバート・グティエレス、NASAのビル・ハガーティ、CabletronシステムゲーリーW); ヘーニー、マーチン・マリエッタエネルギー・システムパトリックHanil、ノキアのテレコミュニケーションマット・ヘヒト、SNMP研究Inc.エドワードA.ハイナー、Jr.、Synernetics株式会社のスーザン・E.ヒックス、マーチンマリエッタエネルギー・システムGeral Holzhauer、アップルジョンHopprich、デヴィッドシステムInc; ジェフ・ヒューズ、ヒューレット・パッカードロビンIddon、軸索はInc.デヴィッド・Itusakケビン・M.ジャクソンをネットワークでつないで、一致コミュニケーションInc.OleはJ.ジェイコブセンです、Interop会社のロナルド・ジャコービー、シリコングラフィックスのサティシュ・ジョーシー、SynOpticsコミュニケーションInc.フランクKastenholz、FTPソフトウェアマークKepke、ヒューレット-パック急性呼吸器病ケンKey、SNMP Research Inc.Zbiginew Kielczewski、Eicon Jongyeoiキム・アンドリュー・クヌーセン・サンタクルスOperationマイケルL.Kornegay、VisiSoftディアドラC.Kostik、BellcoreシェリルKrupczak、ジョージア工科大のマーク・S.ルイス、テレビットデヴィッドリンデヴィッドLindemulder、AT&T/NCRベンLisowski、スプリントのデヴィッド・リュウ、ベル-北Research
Case, McCloghrie, Rose & Waldbusser [Page 19]
ケース、McCloghrie、ローズ、およびWaldbusser[19ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
John Lunny, The Wollongong Group
Robert C. Lushbaugh Martin, Marietta Energy Systems
Michael Luufer, BBN
Carl Madison, Star-Tek, Inc.
Keith McCloghrie, Hughes LAN Systems
Evan McGinnis, 3Com Corporation
Bill McKenzie, IBM Corporation
Donna McMaster, SynOptics Communications, Inc.
John Medicke, IBM Corporation
Doug Miller, Telebit
Dave Minnich, FiberCom
Mohammad Mirhakkak, MITRE
Rohit Mital, Protools
George Mouradian, AT&T Bell Labs
Patrick Mullaney, Cabletron Systems
Dan Myers, 3Com Corporation
Rina Nathaniel, Rad Network Devices Ltd.
Hien V. Nguyen, Sprint
Mo Nikain
Tom Nisbet
William B. Norton, MERIT
Steve Onishi, Wellfleet Communications, Inc.
David T. Perkins, SynOptics Communications, Inc.
Carl Powell, BBN
Ilan Raab, SynOptics Communications, Inc.
Richard Ramons, AT&T
Venkat D. Rangan, Metric Network Systems, Inc.
Louise Reingold, Sprint
Sam Roberts, Farallon Computing, Inc.
Kary Robertson, Concord Communications, Inc.
Dan Romascanu, Lannet Data Communications Ltd.
Marshall T. Rose, Dover Beach Consulting, Inc.
Shawn A. Routhier, Epilogue Technology Corporation
Chris Rozman
Asaf Rubissa, Fibronics
Jon Saperia, Digital Equipment Corporation
Michael Sapich
Mike Scanlon, Interlan
Sam Schaen, MITRE
John Seligson, Ultra Network Technologies
Paul A. Serice, Corporation for Open Systems
Chris Shaw, Banyan Systems
Timon Sloane
Robert Snyder, Cisco Systems
Joo Young Song
ジョンLunny、ウォロンゴンはロバート・C.Lushbaughマーチン、マリエッタエネルギー・システムマイケルLuufer、BBNカール・マディソン、Tekに主演しているInc.キースMcCloghrie、エヴァン・マクギニス、ヒューズLANシステム3Com社のビル・マッケンジーを分類します、IBMの社のドナ・マクマスター、SynOpticsコミュニケーションInc; ジョンMedicke、IBMの社のダグ・ミラー、テレビットのデーヴ・ミンニヒ、FiberComムハマドMirhakkak、斜め継ぎRohit Mital、ProtoolsジョージMouradian、AT&Tのベル研究所のパトリック・マレイニイ、Cabletronシステムダン・マイアーズ、3Com社のリーナ・ナザニエル、radはデバイス株式会社をネットワークでつなぎます; Hien V.Nguyen、Inc.デヴィッド・T.パーキンス、短距離競走Mo NikainトムニスベットウィリアムB.ノートン、長所スティーブ鬼石Wellfleetコミュニケーションカール・パウエル、SynOpticsコミュニケーションInc.BBN宜蘭ラープ、SynOpticsコミュニケーションInc.リチャードRamons、AT&TヴェンカトD.Rangan、Inc.ルイーズ・レインゴールド、メートル法のネットワーク・システムスプリントのサム・ロバーツ、ファラロンコンピューティングInc.Karyロバートソン、一致コミュニケーションInc.ダンRomascanu、Lannetデータ通信株式会社マーシャルT.は上昇しました、ドーヴァービーチConsulting Inc.ショーンA.Routhier、Epilogue Technology社のクリスRozman Asaf Rubissa、FibronicsジョンSaperia、DECのマイケル・Sapichマイク・スキャンロン、InterlanサムSchaen、MITREジョンSeligson、Ultra Network TechnologiesポールA.Serice、オープンSystemsクリス・ショー、Banyan Systemsタイモンスローンロバート・スナイダー、シスコシステムズJooヤングSongへの社
Case, McCloghrie, Rose & Waldbusser [Page 20]
ケース、McCloghrie、ローズ、およびWaldbusser[20ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
Roy Spitier, Sprint
Einar Stefferud, Network Management Associates
John Stephens, Cayman Systems, Inc.
Robert L. Stewart, Xyplex, Inc. (chair)
Kaj Tesink, Bellcore
Dean Throop, Data General
Ahmet Tuncay, France Telecom-CNET
Maurice Turcotte, Racal Datacom
Warren Vik, INTERACTIVE Systems Corporation
Yannis Viniotis
Steven L. Waldbusser, Carnegie Mellon Universitty
Timothy M. Walden, ACC
Alice Wang, Sun Microsystems
James Watt, Newbridge
Luanne Waul, Timeplex
Donald E. Westlake III, Digital Equipment Corporation
Gerry White
Bert Wijnen, IBM Corporation
Peter Wilson, 3Com Corporation
Steven Wong, Digital Equipment Corporation
Randy Worzella, IBM Corporation
Daniel Woycke, MITRE
Honda Wu
Jeff Yarnell, Protools
Chris Young, Cabletron
Kiho Yum, 3Com Corporation
ロイSpitier、短距離競走Einar Stefferud、ネットワークマネージメントはジョン・スティーブンス(ケイマンシステムInc.ロバート・L.スチュワート、Xyplex Inc.(いす)カイTesink(BellcoreディーンThroop)データゼネラルのAhmet Tuncay、フランステレコム-CNETモーリスTurcotte、Racal Datacomウォレン・ビークインタラクティブシステム社のヤニスViniotisスティーブンL.Waldbusserカーネギー・メロン・UniversittyティモシーM)を関連づけます; ウォルデン、ACCアリスワング、サン・マイクロシステムズのジェームズ・ワット、NewbridgeルアンWaul、Timeplexドナルド・E.ウェストレークIII、DECゲリーホワイトバートWijnen、IBMの社のピーター・ウィルソン、3Com社のスティーブンWong、DECランディWorzella、IBM社のダニエルWoycke、斜め継ぎホンダウージェフYarnell、Protoolsクリス・ヤング、おいしいCabletron Kiho3Com社
Case, McCloghrie, Rose & Waldbusser [Page 21]
ケース、McCloghrie、ローズ、およびWaldbusser[21ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
10. References
10. 参照
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[1] ケース、J.、McCloghrie、K.、ローズ、M.、およびWaldbusser、S.は「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためにOperationsについて議定書の中で述べます」、RFC1448、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学、1993年4月。
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[2] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[3] Information processing systems - Open Systems
Interconnection - Transport Service Definition,
International Organization for Standardization.
International Standard 8072, (June, 1986).
[3] 情報処理システム(オープン・システム・インターコネクション)はService Definition、国際標準化機構を輸送します。 国際規格8072、(1986年6月。)
[4] Information processing systems - Open Systems
Interconnection - Transport Service Definition - Addendum
1: Connectionless-mode Transmission, International
Organization for Standardization. International Standard
8072/AD 1, (December, 1986).
[4]情報処理システム--オープン・システム・インターコネクション--輸送Service Definition--付加物1: コネクションレス型伝送、国際標準化機構。 国際規格西暦1年、8072/(1986年12月。)
[5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk
(second edition). Addison-Wesley, 1990.
[5] G.Sidhu、R.アンドリュース、A.オッペンハイマー、Inside AppleTalk(第2版)。 アディソン-ウエスリー、1990。
[6] Waldbusser, S., "AppleTalk Management Information Base",
RFC 1243, Carnegie Mellon University, July 1991.
[6]Waldbusser、S.、「AppleTalk管理情報ベース」、RFC1243、カーネギメロン大学、1991年7月。
[7] Network System Technical Interface Overview. Novell,
Inc, (June, 1989).
[7] システム技術的インタフェース概要をネットワークでつないでください。 ノベル、Inc(1989年6月)。
[8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP
Research, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[8] ケース、J.、ヒョードル、M.、Schoffstall、M.、デーヴィン、J.、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework", RFC
1452, SNMP Research, Inc., Hughes LAN Systems, Dover
Beach Consulting, Inc., Carnegie Mellon University, April
1993.
[9] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「インターネット標準Network Management Frameworkのバージョン1とバージョン2の間の共存」RFC1452、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[10] McCloghrie, K., and Galvin, J., "Party MIB for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC
[10] McCloghrie、K.とガルビン、J.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのパーティMIB」RFC
Case, McCloghrie, Rose & Waldbusser [Page 22]
ケース、McCloghrie、ローズ、およびWaldbusser[22ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
1447, Hughes LAN Systems, Trusted Information Systems,
April 1993.
1447(ヒューズLANシステム)は情報システム、1993年4月を信じました。
[11] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[11] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)(国際標準化機構)のためのBasic Encoding Rulesの仕様。 国際規格8825、(1987年12月。)
Case, McCloghrie, Rose & Waldbusser [Page 23]
ケース、McCloghrie、ローズ、およびWaldbusser[23ページ]
RFC 1449 Transport Mappings for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1449輸送マッピング
11. Security Considerations
11. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
12. Authors' Addresses
12. 作者のアドレス
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
ジェフリーD.ケースSNMP研究Inc.3001Kimberlin Heights通り ノクスビル、テネシー37920-9716米国
Phone: +1 615 573 1434
Email: case@snmp.com
以下に電話をしてください。 +1 1434年の615 573メール: case@snmp.com
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US
キースMcCloghrieヒューズLANシステム1225チャールストンRoadカリフォルニア94043マウンテンビュー(米国)
Phone: +1 415 966 7934
Email: kzm@hls.com
以下に電話をしてください。 +1 7934年の415 966メール: kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 1052年の415 968メール: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
4910 Forbes Ave
Pittsburgh, PA 15213
US
スティーブンWaldbusserカーネギーメロン大学4910フォーブズ・Ave PA15213ピッツバーグ(米国)
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
以下に電話をしてください。 +1 6628年の412 268メール: waldbusser@cmu.edu
Case, McCloghrie, Rose & Waldbusser [Page 24]
ケース、McCloghrie、ローズ、およびWaldbusser[24ページ]
一覧
スポンサーリンク
