RFC1905 日本語訳
1905 Protocol Operations for Version 2 of the Simple NetworkManagement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.Waldbusser. January 1996. (Format: TXT=55526 bytes) (Obsoletes RFC1448) (Obsoleted by RFC3416) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group SNMPv2 Working Group
Request for Comments: 1905 J. Case
Obsoletes: 1448 SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
コメントを求めるワーキンググループSNMPv2ワーキンググループ要求をネットワークでつないでください: 1905年のJ.ケースは時代遅れにします: 1448年のSNMP研究Inc.カテゴリ: 標準化過程K.McCloghrieシスコシステムズInc.M.はドーヴァービーチコンサルティングInc.S.Waldbusser国際ネットワークサービス1996年1月に上昇しました。
Protocol Operations
for Version 2 of the
Simple Network Management Protocol (SNMPv2)
簡単なネットワーク管理プロトコルのバージョン2のためのプロトコル操作(SNMPv2)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
1. Introduction
1. 序論
A 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 authentication, authorization, access control, and privacy policies.
マネージメントシステムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証、承認、アクセスコントロール、およびプライバシーに関する方針を定義する管理フレームワークの下で行われます。
Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
管理局は管理された要素をモニターして、制御する管理アプリケーションを作成します。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2].
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 Management情報(SMI)[2]のStructureは、これらのモジュールがOSIの抽象的なSyntax Notation One(ASN.1)[1]の部分集合を使用することで書かれていると呼びました。
SNMPv2 Working Group Standards Track [Page 1] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[1ページ]RFC1905プロトコル操作
The management protocol, version 2 of the Simple Network Management Protocol, provides for the exchange of messages which convey management information between the agents and the management stations. The form of these messages is a message "wrapper" which encapsulates a Protocol Data Unit (PDU). The form and meaning of the "wrapper" is determined by an administrative framework which defines both authentication and authorization policies.
管理プロトコル(Simple Network Managementプロトコルのバージョン2)はエージェントと管理局の間に経営情報を伝えるメッセージの交換に備えます。 これらのメッセージのフォームはプロトコルData Unit(PDU)をカプセル化する「ラッパー」というメッセージです。 「ラッパー」のフォームと意味は認証と承認方針の両方を定義する管理フレームワークで決定します。
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs.
それは、PDUsの送受信に関してプロトコルの操作を定義するためにはこのドキュメント、SNMPv2のためのプロトコルOperationsの目的です。
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 (STD 16), 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2).
博覧会の目的のために、RFCs1155(STD16)、1157年(STD15)、および1212年(STD16)に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
2. Overview
2. 概要
2.1. Roles of Protocol Entities
2.1. プロトコル実体の役割
A SNMPv2 entity may operate in a manager role or an agent role.
SNMPv2実体はマネージャの役割かエージェントの役割で作動するかもしれません。
A SNMPv2 entity acts in an agent role when it performs SNMPv2 management operations in response to received SNMPv2 protocol messages (other than an inform notification) or when it sends trap notifications.
受信されたSNMPv2プロトコルメッセージに対応してSNMPv2管理操作を実行するとき、SNMPv2実体がエージェントの役割で行動する、(案内、通知)、または、それはいつ罠通知を送るか。
A SNMPv2 entity acts in a manager role when it initiates SNMPv2 management operations by the generation of SNMPv2 protocol messages or when it performs SNMPv2 management operations in response to received trap or inform notifications.
SNMPv2プロトコルメッセージの世代によるSNMPv2管理操作を開始するとき、SNMPv2実体がマネージャの役割で行動するか、または働くとき、受け取られていることに対応したSNMPv2管理操作は、捕らえるか、通知を知らせます。
A SNMPv2 entity may support either or both roles, as dictated by its implementation and configuration. Further, a SNMPv2 entity can also act in the role of a proxy agent, in which it appears to be acting in an agent role, but satisfies management requests by acting in a manager role with a remote entity.
SNMPv2実体はその実装と構成によって書き取られるようにどちらかか役割の両方をサポートするかもしれません。 また、さらに、SNMPv2実体はプロキシエージェントの役割で行動できます。(そこでは、それは、エージェントの役割で行動しているように見えますが、リモート実体でマネージャの役割で行動することによって、管理要求を満たします)。
2.2. Management Information
2.2. 経営情報
The term, variable, refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [2] or the textual conventions based on the SMI [3]. The term, variable binding, normally refers to the pairing of the name of a variable and
可変である用語はSMI[2]に詳しく説明されたコンベンションかSMI[3]に基づく原文のコンベンションに従って定義された非集団オブジェクトタイプのインスタンスについて言及します。 そして通常、用語(変項束縛)が変数の名前の組み合わせについて言及する。
SNMPv2 Working Group Standards Track [Page 2] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[2ページ]RFC1905プロトコル操作
its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception.
関連値。 しかしながら、ある種類の例外的な状態が検索要求の処理の間、現れると、変項束縛はその例外の名前としるしを対にするでしょう。
A variable-binding list is a simple list of variable bindings.
変項束縛リストは変項束縛に関する単純並びです。
The name of a variable is an OBJECT IDENTIFIER which is the concatenation of the OBJECT IDENTIFIER of the corresponding object- type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable.
インスタンスを特定するOBJECT IDENTIFIER断片と共に変数の名前は対応するオブジェクトタイプのOBJECT IDENTIFIERの連結であるOBJECT IDENTIFIERです。 対応するオブジェクト・タイプのOBJECT IDENTIFIERは変数のOBJECT IDENTIFIER接頭語と呼ばれます。
2.3. Access to Management Information
2.3. 経営情報へのアクセス
Three types of access to management information are provided by the protocol. One type is a request-response interaction, in which a SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2 entity, acting in an agent role, and the latter SNMPv2 entity then responds to the request. This type is used to retrieve or modify management information associated with the managed device.
プロトコルは経営情報へのアクセスの3つのタイプを提供します。 エージェントの役割で行動して、1つのタイプが要求応答相互作用です、そして、次に、後者のSNMPv2実体は要求に応じます。(マネージャの役割で行動して、SNMPv2実体はそれでSNMPv2実体に要求を送ります)。 このタイプは、管理されたデバイスに関連している経営情報を検索するか、または変更するのに使用されます。
A second type is also a request-response interaction, in which a SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2 entity, also acting in a manager role, and the latter SNMPv2 entity then responds to the request. This type is used to notify a SNMPv2 entity, acting in a manager role, of management information associated with another SNMPv2 entity, also acting in a manager role.
また、2番目のタイプは要求応答相互作用です、そして、次に、後者のSNMPv2実体は要求に応じます。(SNMPv2実体(マネージャの役割における芝居)はそれでSNMPv2実体、マネージャの役割における芝居にも要求を送ります)。 このタイプはSNMPv2実体に通知するのに使用されます、別のSNMPv2実体に関連している経営情報のマネージャの役割で行動して、また、マネージャの役割で行動して。
The third type of access is an unconfirmed interaction, in which a SNMPv2 entity, acting in an agent role, sends a unsolicited message, termed a trap, to a SNMPv2 entity, acting in a manager role, and no response is returned. This type is used to notify a SNMPv2 entity, acting in a manager role, of an exceptional situation, which has resulted in changes to management information associated with the managed device.
3番目のタイプのアクセスは未確認の相互作用です、マネージャの役割における芝居、そして、応答を全く返しません。(そこでは、SNMPv2実体(エージェントの役割における芝居)は罠と呼ばれたお節介なメッセージをSNMPv2実体に送ります)。 このタイプはSNMPv2実体に通知するのに使用されます、管理されたデバイスに関連している経営情報への変化をもたらした例外的な状況のマネージャの役割で行動して。
2.4. Retransmission of Requests
2.4. 要求のRetransmission
For all types of request in this protocol, the receiver is required under normal circumstances, to generate and transmit a response to the originator of the request. Whether or not a request should be retransmitted if no corresponding response is received in an appropriate time interval, is at the discretion of the application originating the request. This will normally depend on the urgency of the request. However, such an application needs to act responsibly in respect to the frequency and duration of re-transmissions.
このプロトコルにおける、すべてのタイプの要求において、受信機は、要求の創始者への応答を生成して、通常の状況下で伝えなければなりません。 要求が対応する応答でないなら再送されるべきであるかどうかは、適切な時期間隔に受け取られて、要求を溯源するアプリケーションの裁量にはあります。 通常、これは要求の緊急によるでしょう。 しかしながら、そのようなアプリケーションは、再トランスミッションの頻度と持続時間に関して責任を持って行動する必要があります。
SNMPv2 Working Group Standards Track [Page 3] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[3ページ]RFC1905プロトコル操作
2.5. Message Sizes
2.5. メッセージサイズ
The maximum size of a SNMPv2 message is limited to the minimum of:
SNMPv2メッセージの最大サイズは以下の最小限に制限されます。
(1) the maximum message size which the destination SNMPv2 entity can
accept; and,
(1) 目的地SNMPv2実体が受け入れることができる最大のメッセージサイズ。 そして
(2) the maximum message size which the source SNMPv2 entity can
generate.
(2) ソースSNMPv2実体が生成することができる最大のメッセージサイズ。
The former may be known on a per-recipient basis; and in the absence of such knowledge, is indicated by transport domain used when sending the message. The latter is imposed by implementation-specific local constraints.
前者は1受取人あたり1個のベースで知られているかもしれません。 そして、そのようなものが不在のとき、知識は輸送で示されて、ドメインがメッセージを送りながらいつを使用したかということです。 後者は実装特有の地方の規制で課されます。
Each transport mapping for the SNMPv2 indicates the minimum message size which a SNMPv2 implementation must be able to produce or consume. Although implementations are encouraged to support larger values whenever possible, a conformant implementation must never generate messages larger than allowed by the receiving SNMPv2 entity.
SNMPv2のためのそれぞれの輸送マッピングはSNMPv2実装が生産しなければならないか、または消費できなければならない最小のメッセージサイズを示します。 可能であるときはいつも、実装が、より大きい値をサポートするよう奨励されますが、conformant実装は受信SNMPv2実体によって許容されているより大きいメッセージを決して生成してはいけません。
One of the aims of the GetBulkRequest-PDU, specified in this protocol, is to minimize the number of protocol exchanges required to retrieve a large amount of management information. As such, this PDU type allows a SNMPv2 entity acting in a manager role to request that the response be as large as possible given the constraints on message sizes. These constraints include the limits on the size of messages which the SNMPv2 entity acting in an agent role can generate, and the SNMPv2 entity acting in a manager role can receive.
GetBulkRequest-PDUの目的のこのプロトコルで指定された1つは多量の経営情報を検索するのに必要であるプロトコル交換の数を最小にすることです。 そういうものとして、このPDUタイプはメッセージサイズにおける規制を考えて、応答ができるだけ大きいようマネージャの役割で行動するSNMPv2実体を要求させます。 これらの規制はエージェントの役割におけるSNMPv2実体芝居が生成することができるメッセージのサイズにおける限界を含んでいます、そして、マネージャの役割で行動するSNMPv2実体は受信されることができます。
However, it is possible that such maximum sized messages may be larger than the Path MTU of the path across the network traversed by the messages. In this situation, such messages are subject to fragmentation. Fragmentation is generally considered to be harmful [4], since among other problems, it leads to a decrease in the reliability of the transfer of the messages. Thus, a SNMPv2 entity which sends a GetBulkRequest-PDU must take care to set its parameters accordingly, so as to reduce the risk of fragmentation. In particular, under conditions of network stress, only small values should be used for max-repetitions.
しかしながら、メッセージによって横断されたネットワークの向こう側に、最大の大きさで分けられたメッセージが経路のPath MTUと同じくらい大きいのは、可能です。 この状況で、そのようなメッセージは断片化を受けることがあります。 一般に、断片化は有害な[4]であると考えられます、他の問題の中でメッセージの転送の信頼性の減少に通じるので。 したがって、GetBulkRequest-PDUを送るSNMPv2実体はそれに従って、パラメタを設定するために注意されなければなりません、断片化の危険を減少させるために。 ネットワーク圧力に関する条件のもとで、特に、小さい値だけが最大反復に使用されるべきです。
2.6. Transport Mappings
2.6. 輸送マッピング
It is important to note that the exchange of SNMPv2 messages requires only an unreliable datagram service, with every message being entirely and independently contained in a single transport datagram. Specific transport mappings and encoding rules are specified elsewhere [5]. However, the preferred mapping is the use of the User
SNMPv2メッセージの交換が頼り無いデータグラムサービスだけを必要とすることに注意するのは重要です、あらゆるメッセージが単一の輸送データグラムに完全に独自に含まれている状態で。 特定の輸送マッピングと符号化規則はほかの場所で指定されます。[5]。 しかしながら、都合のよいマッピングはUserの使用です。
SNMPv2 Working Group Standards Track [Page 4] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[4ページ]RFC1905プロトコル操作
Datagram Protocol [6].
データグラムプロトコル[6]。
3. Definitions
3. 定義
SNMPv2-PDU DEFINITIONS ::= BEGIN
SNMPv2-PDU定義:、:= 始まってください。
IMPORTS
ObjectName, ObjectSyntax, Integer32
FROM SNMPv2-SMI;
SNMPv2-SMIからObjectName、ObjectSyntax、Integer32をインポートします。
-- protocol data units
-- プロトコルデータ単位
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
PDUs:、:= CHOICE、要求を得ているGetRequest-PDU
get-next-request
GetNextRequest-PDU,
次の要求を得ているGetNextRequest-PDU
get-bulk-request
GetBulkRequest-PDU,
大量の要求を得ているGetBulkRequest-PDU
response
Response-PDU,
応答Response-PDU
set-request
SetRequest-PDU,
SetRequest-PDUをセット要求してください。
inform-request
InformRequest-PDU,
要求を知らせているInformRequest-PDU
snmpV2-trap
SNMPv2-Trap-PDU,
snmpV2-罠SNMPv2罠PDU
report
Report-PDU,
}
Report-PDUを報告してください。
-- PDUs
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetRequest-PDU:、:= [0] 内在しているPDU
GetNextRequest-PDU ::=
GetNextRequest-PDU:、:=
SNMPv2 Working Group Standards Track [Page 5] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[5ページ]RFC1905プロトコル操作
[1]
IMPLICIT PDU
[1] 内在しているPDU
Response-PDU ::=
[2]
IMPLICIT PDU
応答-PDU:、:= [2] 内在しているPDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
SetRequest-PDU:、:= [3] 内在しているPDU
-- [4] is obsolete
-- [4]は時代遅れです。
GetBulkRequest-PDU ::=
[5]
IMPLICIT BulkPDU
GetBulkRequest-PDU:、:= [5] 内在しているBulkPDU
InformRequest-PDU ::=
[6]
IMPLICIT PDU
InformRequest-PDU:、:= [6] 内在しているPDU
SNMPv2-Trap-PDU ::=
[7]
IMPLICIT PDU
SNMPv2はPDUを捕らえます:、:= [7] 内在しているPDU
-- Usage and precise semantics of Report-PDU are not presently
-- defined. Any SNMP administrative framework making use of
-- this PDU must define its usage and semantics.
Report-PDU ::=
[8]
IMPLICIT PDU
-- 現在、Report-PDUの用法と正確な意味論はそうではありません--定義されます。 使用をするどんなSNMPの管理フレームワーク、も--このPDUはその用法と意味論を定義しなければなりません。 レポート-PDU:、:= [8] 内在しているPDU
max-bindings
INTEGER ::= 2147483647
最大結合INTEGER:、:= 2147483647
PDU ::=
SEQUENCE {
request-id
Integer32,
PDU:、:= SEQUENCE、要求イドInteger32
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
エラー状況--時々INTEGERを無視する、noError(0)、tooBig(1)、プロキシ互換性badValue(3)、プロキシ互換性readOnly(4)、プロキシ互換性genErr(5)のためのnoSuchName(2)
SNMPv2 Working Group Standards Track [Page 6] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[6ページ]RFC1905プロトコル操作
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
noAccess(6)、wrongType(7)、wrongLength(8)、wrongEncoding(9)、wrongValue(10)、noCreation(11)、inconsistentValue(12)、resourceUnavailable(13)、commitFailed(14)、undoFailed(15)、authorizationError(16)、notWritable(17)、inconsistentName(18)
error-index -- sometimes ignored
INTEGER (0..max-bindings),
誤りインデックス--時々無視されたINTEGER(0..max-結合)
variable-bindings -- values are sometimes ignored
VarBindList
}
変項束縛--値は時々無視されたVarBindListです。
BulkPDU ::= -- MUST be identical in
SEQUENCE { -- structure to PDU
request-id
Integer32,
BulkPDU:、:= -- SEQUENCEで同じでなければならない、--PDU要求イドInteger32への構造
non-repeaters
INTEGER (0..max-bindings),
非リピータINTEGER(0..max-結合)
max-repetitions
INTEGER (0..max-bindings),
最大反復INTEGER(0..max-結合)
variable-bindings -- values are ignored
VarBindList
}
変項束縛--値は無視されたVarBindListです。
-- variable binding
-- 変項束縛
VarBind ::=
SEQUENCE {
name
ObjectName,
VarBind:、:= SEQUENCE、ObjectNameを命名してください。
CHOICE {
value
CHOICE、値
SNMPv2 Working Group Standards Track [Page 7] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[7ページ]RFC1905プロトコル操作
ObjectSyntax,
ObjectSyntax
unSpecified -- in retrieval requests
NULL,
unSpecifiedされました--検索では、NULLを要求します。
-- exceptions in responses
noSuchObject[0]
IMPLICIT NULL,
-- 応答noSuchObject[0] IMPLICIT NULLの例外
noSuchInstance[1]
IMPLICIT NULL,
noSuchInstance[1]の暗黙のヌル
endOfMibView[2]
IMPLICIT NULL
}
}
endOfMibView[2]の暗黙のヌル }
-- variable-binding list
-- 変項束縛リスト
VarBindList ::=
SEQUENCE (SIZE (0..max-bindings)) OF
VarBind
VarBindList:、:= VarBindの系列(サイズ(0..max-結合))
END
終わり
4. Protocol Specification
4. プロトコル仕様
4.1. Common Constructs
4.1. 一般的な構造物
The value of the request-id field in a Response-PDU takes the value of the request-id field in the request PDU to which it is a response. By use of the request-id value, a SNMPv2 application can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is used, the request-id also provides a simple means of identifying messages duplicated by the network. Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request. However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the SNMPv2 application needs to use a different request-id value on a retransmitted request. The latter strategy is recommended for use in the majority of situations.
Response-PDUの要求イド分野の値はそれが応答である要求PDUにおける、要求イド分野の値を取ります。 要求イド価値の使用で、SNMPv2アプリケーションは、(潜在的に複数)の傑出している要求を区別して、その結果、傑出している要求で入って来る応答を関連させることができます。 また、頼り無いデータグラムサービスが使用されている場合では、要求イドはネットワークによってコピーされたメッセージを特定する簡潔な方法を提供します。 要求の「再-トランスミッション」における同じ要求イドの使用で、オリジナルのトランスミッションか「再-トランスミッション」のどちらかへの応答は要望に応じることができます。 しかしながら、要求応答トランザクションのトランスミッションと処理のための周遊旅行時間について計算するために、SNMPv2アプリケーションは、再送された要求の異なった要求イド値を使用する必要があります。 後者の戦略は状況の大部分における使用のために推薦されます。
SNMPv2 Working Group Standards Track [Page 8] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[8ページ]RFC1905プロトコル操作
A non-zero value of the error-status field in a Response-PDU is used to indicate that an exception occurred to prevent the processing of the request. In these cases, a non-zero value of the Response-PDU's error-index field provides additional information by identifying which variable binding in the list caused the exception. A variable binding is identified by its index value. The first variable binding in a variable-binding list is index one, the second is index two, etc.
Response-PDUのエラー状況分野の非ゼロ値は、例外が要求の処理を防ぐために起こったのを示すのに使用されます。 これらの場合では、リストにおけるどの変項束縛が例外を引き起こしたかを特定することによって、Response-PDUの誤りインデックス部の非ゼロ値は追加情報を提供します。 変項束縛はインデックス値によって特定されます。 変項束縛リストにおける最初の変項束縛がインデックス1である、2番目はインデックスtwoですなど。
SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub- identifiers, where each sub-identifier has a maximum value of 2**32- 1.
SNMPv2はOBJECT IDENTIFIER値を最大128のサブ識別子に制限します。そこでは、それぞれのサブ識別子が2**32- 1の最大値を持っています。
4.2. PDU Processing
4.2. PDU処理
It is mandatory that all SNMPv2 entities acting in an agent role be able to generate the following PDU types: Response-PDU and SNMPv2- Trap-PDU; further, all such implementations must be able to receive the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
エージェントの役割で行動するすべてのSNMPv2実体が以下のPDUタイプを生成することができるのは、義務的です: 応答-PDUとSNMPv2罠-PDU。 さらに、そのようなすべての実装が以下のPDUタイプを受けることができなければなりません: GetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、およびSetRequest-PDU。
It is mandatory that all SNMPv2 entities acting in a manager role be able to generate the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, and Response-PDU; further, all such implementations must be able to receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU,
マネージャの役割で行動するすべてのSNMPv2実体が以下のPDUタイプを生成することができるのは、義務的です: GetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、InformRequest-PDU、および応答-PDU。 さらに、そのようなすべての実装が以下のPDUタイプを受けることができなければなりません: 応答-PDU、SNMPv2はPDUを捕らえます。
InformRequest-PDU;
InformRequest-PDU。
In the elements of procedure below, any field of a PDU which is not referenced by the relevant procedure is ignored by the receiving SNMPv2 entity. However, all components of a PDU, including those whose values are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are concerned only with the name of a variable and not its value. In this case, the value portion of the variable binding is ignored by the receiving SNMPv2 entity. The unSpecified value is defined for use as the value portion of such bindings.
以下の手順の要素では、関連手順で参照をつけられないPDUのどんな分野も受信SNMPv2実体によって無視されます。 しかしながら、値が受信SNMPv2実体によって無視されるものを含むPDUのすべての部品には、有効なASN.1構文とコード化がなければなりません。 例えば、いくつかのPDUs(例えば、GetRequest-PDU)が値ではなく、変数の名前だけに関係があります。 この場合、変項束縛の値の部分は受信SNMPv2実体によって無視されます。 unSpecified値は使用のためにそのような結合の値の部分と定義されます。
On generating a management communication, the message "wrapper" to encapsulate the PDU is generated according to the "Elements of Procedure" of the administrative framework in use is followed. While the definition of "max-bindings" does impose an upper-bound on the number of variable bindings, in practice, the size of a message is limited only by constraints on the maximum message size -- it is not limited by the number of variable bindings.
管理がコミュニケーションであると生成すると、カプセル化する「ラッパー」という「手順のElements」に従ってPDUが生成される使用中の管理フレームワークに関するメッセージは従われています。 「最大結合」の定義が変項束縛の数に上限を課している間、実際には、メッセージのサイズは最大のメッセージサイズで単に規制で制限されます--それは変項束縛の数によって制限されません。
SNMPv2 Working Group Standards Track [Page 9] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[9ページ]RFC1905プロトコル操作
On receiving a management communication, the "Elements of Procedure" of the administrative framework in use is followed, and if those procedures indicate that the operation contained within the message is to be performed locally, then those procedures also indicate the MIB view which is visible to the operation.
使用中の管理フレームワークについてマネジメント・コミュニケーション、「手順の要素」を受けるところに、続かれていて、それらの手順が、メッセージの中に含まれた操作が局所的に実行されることであり、次に、また、それらの手順がMIBを示すのを示すなら、操作に目に見える視点があります。
4.2.1. The GetRequest-PDU
4.2.1. GetRequest-PDU
A GetRequest-PDU is generated and transmitted at the request of a SNMPv2 application.
GetRequest-PDUはSNMPv2アプリケーションの依頼で生成されて、伝えられます。
Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. Each variable binding is processed as follows:
GetRequest-PDUを受け取り次第、受信SNMPv2実体は、Response-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response-PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。 各変項束縛は以下の通り処理されます:
(1) If the variable binding's name exactly matches the name of a
variable accessible by this request, then the variable binding's
value field is set to the value of the named variable.
(1) 変項束縛の名前がまさにこの要求でアクセスしやすい変数の名前に合っているなら、変項束縛の値の分野は名前付き変数の値に設定されます。
(2) Otherwise, if the variable binding's name does not have an OBJECT
IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER
prefix of any (potential) variable accessible by this request, then
its value field is set to `noSuchObject'.
(2) さもなければ、変項束縛の名前にまさにこの要求でアクセスしやすいどんな(潜在的)の変数のOBJECT IDENTIFIER接頭語にも合っているOBJECT IDENTIFIER接頭語がないなら、値の分野は'noSuchObject'に設定されます。
(3) Otherwise, the variable binding's value field is set to
`noSuchInstance'.
(3) さもなければ、変項束縛の値の分野は'noSuchInstance'に設定されます。
If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetRequest-PDU, with the value of its error-status field set to `genErr', and the value of its error-index field is set to the index of the failed variable binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field is set to `noError', and the value of its error-index field is zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです。
The generated Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU.
そして、発生しているResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはGetRequest-PDUの創始者に伝えられます。
Otherwise, an alternate Response-PDU is generated. This alternate Response-PDU is formatted with the same value in its request-id field as the received GetRequest-PDU, with the value of its error-status field set to `tooBig', the value of its error-index field set to
さもなければ、代替のResponse-PDUは発生しています。 この代替のResponse-PDUは誤りインデックス部の値が'tooBig'に設定されたエラー状況分野の値でセットした容認されたGetRequest-PDUとして要求イド分野で同じ値でフォーマットされます。
SNMPv2 Working Group Standards Track [Page 10] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[10ページ]RFC1905プロトコル操作
zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded.
ゼロ、および人影のない変項束縛分野。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはGetRequest-PDUの創始者に伝えられます。 さもなければ、snmpSilentDrops[9]カウンタは増加されています、そして、結果のメッセージは捨てられます。
4.2.2. The GetNextRequest-PDU
4.2.2. GetNextRequest-PDU
A GetNextRequest-PDU is generated and transmitted at the request of a SNMPv2 application.
GetNextRequest-PDUはSNMPv2アプリケーションの依頼で生成されて、伝えられます。
Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. Each variable binding is processed as follows:
GetNextRequest-PDUを受け取り次第、受信SNMPv2実体は、Response-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response-PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。 各変項束縛は以下の通り処理されます:
(1) The variable is located which is in the lexicographically ordered
list of the names of all variables which are accessible by this
request and whose name is the first lexicographic successor of the
variable binding's name in the incoming GetNextRequest-PDU. The
corresponding variable binding's name and value fields in the
Response-PDU are set to the name and value of the located variable.
(1) すべてのこの要求でアクセスしやすい変数の名前の辞書編集の規則正しいリストにあって、名前が第1代入って来るGetNextRequest-PDUの変項束縛の名前の辞書編集の後継者である変数は、見つけられています。 Response-PDUの対応する変項束縛の名前と値の分野は見つけられた変数の名前と値に設定されます。
(2) If the requested variable binding's name does not lexicographically
precede the name of any variable accessible by this request, i.e.,
there is no lexicographic successor, then the corresponding
variable binding produced in the Response-PDU has its value field
set to `endOfMibView', and its name field set to the variable
binding's name in the request.
(2) 要求された変項束縛の名前が辞書編集にこの要求でアクセスしやすいどんな変数の名前にも先行しないなら、すなわち、どんな辞書編集の後継者もいませんでした、そして、次に、Response-PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は要求における変項束縛の名前にセットしました。
If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetNextRequest-PDU, with the value of its error-status field set to `genErr', and the value of its error-index field is set to the index of the failed variable binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetNextRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field is set to `noError', and the value of its error-index field is zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです。
The generated Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextRequest-PDU.
そして、発生しているResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはGetNextRequest-PDUの創始者に伝えられます。
SNMPv2 Working Group Standards Track [Page 11] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[11ページ]RFC1905プロトコル操作
Otherwise, an alternate Response-PDU is generated. This alternate Response-PDU is formatted with the same values in its request-id field as the received GetNextRequest-PDU, with the value of its error-status field set to `tooBig', the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded.
さもなければ、代替のResponse-PDUは発生しています。 この代替のResponse-PDUは容認されたGetNextRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない変項束縛分野で。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはGetNextRequest-PDUの創始者に伝えられます。 さもなければ、snmpSilentDrops[9]カウンタは増加されています、そして、結果のメッセージは捨てられます。
4.2.2.1. Example of Table Traversal
4.2.2.1. テーブル縦断に関する例
An important use of the GetNextRequest-PDU is the traversal of conceptual tables of information within a MIB. The semantics of this type of request, together with the method of identifying individual instances of objects in the MIB, provides access to related objects in the MIB as if they enjoyed a tabular organization.
GetNextRequest-PDUの重要な使用はMIBの中の情報の概念的なテーブルの縦断です。 まるで彼らが表組織を楽しむかのようにこのタイプの要求の意味論はMIBでオブジェクトの個々のインスタンスを特定するメソッドと共にMIBの関連するオブジェクトへのアクセスを提供します。
In the protocol exchange sketched below, a SNMPv2 application retrieves the media-dependent physical address and the address- mapping type for each entry in the IP net-to-media Address Translation Table [7] of a particular network element. It also retrieves the value of sysUpTime [9], at which the mappings existed. Suppose that the agent's IP net-to-media table has three entries:
以下にスケッチされたプロトコル交換では、SNMPv2アプリケーションは、特定のネットワーク要素のネットからメディアへのIP Address Translation Table[7]の各エントリーのためのタイプを写像しながら、メディア依存する物理アドレスとアドレスを検索します。 また、それはsysUpTime[9]の値を検索します。(そこでは、マッピングが存在しました)。 IPネットからメディアへのエージェントのテーブルには3つのエントリーがあると仮定してください:
Interface-Number Network-Address Physical-Address Type
インタフェース番号ネットワーク・アドレス物理アドレスタイプ
1 10.0.0.51 00:00:10:01:23:45 static
1 9.2.3.4 00:00:10:54:32:10 dynamic
2 10.0.0.15 00:00:10:98:76:54 dynamic
1 10.0.0.51 00:、01:23:45、00:10:静的な1 9.2.3.4 00:、54:32:10、00:10:ダイナミックな2 10.0.0.15 00:、98:76:54、00:10:ダイナミック
The SNMPv2 entity acting in a manager role begins by sending a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names:
マネージャの役割で行動するSNMPv2実体は要求された変数名として示されたOBJECT IDENTIFIER値を含むGetNextRequest-PDUを送ることによって、始まります:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType)
The SNMPv2 entity acting in an agent role responds with a Response- PDU:
エージェントの役割で行動するSNMPv2実体はResponse- PDUと共に応じます:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
応答(sysUpTime.0=「123456」)、(ipNetToMediaPhysAddress.1.9.2.3.4=、「000010543210」)、(ipNetToMediaType.1.9.2.3.4=「動力」)
SNMPv2 Working Group Standards Track [Page 12] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[12ページ]RFC1905プロトコル操作
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.9.2.3.4,
ipNetToMediaType.1.9.2.3.4 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.1 .9 .2 .3 .4、ipNetToMediaType.1.9、.2、.3、.4)
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123461" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
応答(sysUpTime.0=「123461」)、(ipNetToMediaPhysAddress.1.10.0.0.51=、「000010012345」)、(ipNetToMediaType.1.10.0.0.51=「静的」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.1 .10 .0 .0 .51、ipNetToMediaType.1.10、.0、.0、.51)
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
応答(sysUpTime.0=「123466」)、(ipNetToMediaPhysAddress.2.10.0.0.15=、「000010987654」)、(ipNetToMediaType.2.10.0.0.15=「動力」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.2.10.0.0.15,
ipNetToMediaType.2.10.0.0.15 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.2 .10 .0 .0 .15、ipNetToMediaType.2.10、.0、.0、.15)
As there are no further entries in the table, the SNMPv2 entity acting in an agent role responds with the variables that are next in the lexicographical ordering of the accessible object names, for example:
エントリーがこれ以上テーブルにないとき、エージェントの役割で行動するSNMPv2実体は例えばアクセスしやすいオブジェクト名の辞書編集の注文で次の変数で応じます:
Response (( sysUpTime.0 = "123471" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
応答(sysUpTime.0=「123471」)、(ipNetToMediaNetAddress.1.9.2.3.4=、「9.2 .3 0.4インチ)、(ipRoutingDiscards.0が等しい、「2インチ)」
This response signals the end of the table to the SNMPv2 entity acting in a manager role.
この応答はマネージャの役割で行動するSNMPv2実体にテーブルの端を示します。
SNMPv2 Working Group Standards Track [Page 13] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[13ページ]RFC1905プロトコル操作
4.2.3. The GetBulkRequest-PDU
4.2.3. GetBulkRequest-PDU
A GetBulkRequest-PDU is generated and transmitted at the request of a SNMPv2 application. The purpose of the GetBulkRequest-PDU is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables.
GetBulkRequest-PDUはSNMPv2アプリケーションの依頼で生成されて、伝えられます。 GetBulkRequest-PDUの目的は潜在的に大データ量の転送を要求することです、含んでいます、他、大きいテーブルの効率的で急速な検索。
Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU with its request-id field having the same value as in the request. Processing begins by examining the values in the non-repeaters and max-repetitions fields. If the value in the non-repeaters field is less than zero, then the value of the field is set to zero. Similarly, if the value in the max-repetitions field is less than zero, then the value of the field is set to zero.
GetBulkRequest-PDUを受け取り次第、受信SNMPv2実体は、要求のように同じ値を持っている要求イド分野があるResponse-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 処理は、非リピータと最大反復分野で値を調べることによって、始まります。 非リピータ分野の値がゼロ未満であるなら、分野の値はゼロに設定されます。 同様に、分野の値は最大反復分野の値がゼロ未満であるならゼロに設定されます。
For the GetBulkRequest-PDU type, the successful processing of each variable binding in the request generates zero or more variable bindings in the Response-PDU. That is, the one-to-one mapping between the variable bindings of the GetRequest-PDU, GetNextRequest- PDU, and SetRequest-PDU types and the resultant Response-PDUs does not apply for the mapping between the variable bindings of a GetBulkRequest-PDU and the resultant Response-PDU.
GetBulkRequest-PDUタイプのために、要求における、それぞれの変項束縛のうまくいっている処理はResponse-PDUでゼロか、より可変な結合を生成します。 すなわち、GetRequest-PDU、GetNextRequest- PDU、SetRequest-PDUタイプ、および結果のResponse-PDUsの変項束縛の間の1〜1つのマッピングはGetBulkRequest-PDUと結果のResponse-PDUの変項束縛の間でマッピングに申し込みません。
The values of the non-repeaters and max-repetitions fields in the request specify the processing requested. One variable binding in the Response-PDU is requested for the first N variable bindings in the request and M variable bindings are requested for each of the R remaining variable bindings in the request. Consequently, the total number of requested variable bindings communicated by the request is given by N + (M * R), where N is the minimum of: a) the value of the non-repeaters field in the request, and b) the number of variable bindings in the request; M is the value of the max-repetitions field in the request; and R is the maximum of: a) number of variable bindings in the request - N, and b) zero.
要求における、非リピータと最大反復分野の値は要求された処理を指定します。 Response-PDUの1つの変項束縛が要求における最初のN変項束縛のために要求されています、そして、M可変な結合は、それぞれのRのために要求で変項束縛のままで残りながら、要求されています。 その結果、N+(M*R)で要求で伝えられた要求された変項束縛の総数をNが最小限であるところに与えます: a) b) 要求における、非リピータ分野の値、および要求における、変項束縛の数。 Mは要求で、最大反復分野の値です。 そして、Rは以下の最大です。 a) 要求における、変項束縛の数--b) N、およびゼロ。
The receiving SNMPv2 entity produces a Response-PDU with up to the total number of requested variable bindings communicated by the request. The request-id shall have the same value as the received GetBulkRequest-PDU.
要求された変項束縛の総数が要求で伝えられている状態で、受信SNMPv2実体はResponse-PDUを生産します。 要求イドには、容認されたGetBulkRequest-PDUと同じ値があるものとします。
If N is greater than zero, the first through the (N)-th variable bindings of the Response-PDU are each produced as follows:
ゼロ以上、第1がNであるなら突き抜けている、(N)、-、第Response-PDUの変項束縛は以下の通りそれぞれ起こされます:
(1) The variable is located which is in the lexicographically ordered
list of the names of all variables which are accessible by this
request and whose name is the first lexicographic successor of the
(1) すべてのこの要求と名前が第1代だれのもので辞書編集の後継者であるかがアクセスしやすい変数の名前の辞書編集の規則正しいリストにある変数は見つけられています。
SNMPv2 Working Group Standards Track [Page 14] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[14ページ]RFC1905プロトコル操作
variable binding's name in the incoming GetBulkRequest-PDU. The
corresponding variable binding's name and value fields in the
Response-PDU are set to the name and value of the located variable.
入って来るGetBulkRequest-PDUの変項束縛の名前。 Response-PDUの対応する変項束縛の名前と値の分野は見つけられた変数の名前と値に設定されます。
(2) If the requested variable binding's name does not lexicographically
precede the name of any variable accessible by this request, i.e.,
there is no lexicographic successor, then the corresponding
variable binding produced in the Response-PDU has its value field
set to `endOfMibView', and its name field set to the variable
binding's name in the request.
(2) 要求された変項束縛の名前が辞書編集にこの要求でアクセスしやすいどんな変数の名前にも先行しないなら、すなわち、どんな辞書編集の後継者もいませんでした、そして、次に、Response-PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は要求における変項束縛の名前にセットしました。
If M and R are non-zero, the (N + 1)-th and subsequent variable bindings of the Response-PDU are each produced in a similar manner. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated variable, r, such that r is greater than zero and less than or equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of the Response-PDU is produced as follows:
第そして、MとRが非ゼロであるなら(N+1)、-、Response-PDUのその後の変項束縛はそれぞれ同じように起こされます。 各繰り返し、それぞれの繰り返された変数のためのi、iがゼロと、よりMよりすばらしいようなものとrとrがさらにゼロ以上であるようにものとR、(N+(i-1)*R)+よりr)、-、第Response-PDUの変項束縛は以下の通り起こされます:
(1) The variable which is in the lexicographically ordered list of the
names of all variables which are accessible by this request and
whose name is the (i)-th lexicographic successor of the (N + r)-th
variable binding's name in the incoming GetBulkRequest-PDU is
located and the variable binding's name and value fields are set to
the name and value of the located variable.
(1) この要求でアクセスしやすく、名前があるすべての変数の名前の辞書編集の規則正しいリストにある変数、(i)、-、(N+r)の辞書編集の第後継者、-、入って来るGetBulkRequest-PDUの変項束縛の名前は見つけられていて、変項束縛の名前と値の分野は見つけられた変数の名前と値に第設定されます。
(2) If there is no (i)-th lexicographic successor, then the
corresponding variable binding produced in the Response-PDU has its
value field set to `endOfMibView', and its name field set to either
the last lexicographic successor, or if there are no lexicographic
successors, to the (N + r)-th variable binding's name in the
request.
(2) いいえがある、(i)、-、辞書編集の後継者、次に、Response-PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は最後の辞書編集の後継者かそれともどんな辞書編集の後継者もいないかどうかにセットしました、(N+r)に第-、要求における変項束縛の第名前。
While the maximum number of variable bindings in the Response-PDU is bounded by N + (M * R), the response may be generated with a lesser number of variable bindings (possibly zero) for either of three reasons.
Response-PDUの変項束縛の最大数は境界がある間、+ (M*R)、Nによる応答は3つの理由のどちらかのための、より少ない数の変項束縛(ことによるとゼロ)で生成されるかもしれません。
(1) If the size of the message encapsulating the Response-PDU
containing the requested number of variable bindings would be
greater than either a local constraint or the maximum message size
of the originator, then the response is generated with a lesser
number of variable bindings. This lesser number is the ordered set
of variable bindings with some of the variable bindings at the end
of the set removed, such that the size of the message encapsulating
the Response-PDU is approximately equal to but no greater than
either a local constraint or the maximum message size of the
originator. Note that the number of variable bindings removed has
no relationship to the values of N, M, or R.
(1) 変項束縛の要求された数を含むResponse-PDUをカプセル化するメッセージのサイズが創始者の地方の規制か最大のメッセージサイズのどちらかより大きいなら、応答は、より少ない数の変項束縛で生成されます。 このより少ない数はセットの端の変項束縛のいくつかを取り除いている変項束縛の順序集合です、Response-PDUをカプセル化するメッセージのサイズが地方の、より規制か創始者の最大のメッセージサイズだけとほとんど等しいように。 取り除かれた変項束縛の数にはN、M、またはRの値との関係が全くないことに注意してください。
SNMPv2 Working Group Standards Track [Page 15] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[15ページ]RFC1905プロトコル操作
(2) The response may also be generated with a lesser number of variable
bindings if for some value of iteration i, such that i is greater
than zero and less than or equal to M, that all of the generated
variable bindings have the value field set to the `endOfMibView'.
In this case, the variable bindings may be truncated after the (N +
(i * R))-th variable binding.
(2) また、繰り返しi(iがゼロと、よりMよりすばらしく、発生している変項束縛のすべてが'endOfMibView'に値の分野を設定させるようなもの)の何らかの値のために応答は、より少ない数の変項束縛で生成されるかもしれません。 この場合変項束縛が先端を切られたかもしれない後、(N+(i*R))、-、第変項束縛。
(3) In the event that the processing of a request with many repetitions
requires a significantly greater amount of processing time than a
normal request, then an agent may terminate the request with less
than the full number of repetitions, providing at least one
repetition is completed.
(3) 多くの反復による要求の処理が通常の要求よりかなり大きい量の処理時間を必要とする場合、次に、エージェントは反復の定員以下で要求を終えるかもしれません、少なくとも1つの反復が終了されているなら。
If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetBulkRequest-PDU, with the value of its error-status field set to `genErr', and the value of its error-index field is set to the index of the variable binding in the original request which corresponds to the failed variable binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetBulkRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛に対応するオリジナルの要求における、変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field is set to `noError', and the value of its error-index field to zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'、およびゼロへの誤りインデックス部の値に設定されます。
The generated Response-PDU (possibly with an empty variable-bindings field) is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetBulkRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded.
そして、発生しているResponse-PDU(ことによると人影のない変項束縛分野がある)はメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはGetBulkRequest-PDUの創始者に伝えられます。 さもなければ、snmpSilentDrops[9]カウンタは増加されています、そして、結果のメッセージは捨てられます。
4.2.3.1. Another Example of Table Traversal
4.2.3.1. テーブル縦断に関する別の例
This example demonstrates how the GetBulkRequest-PDU can be used as an alternative to the GetNextRequest-PDU. The same traversal of the IP net-to-media table as shown in Section 4.2.2.1 is achieved with fewer exchanges.
この例はGetNextRequest-PDUに代わる手段としてどうGetBulkRequest-PDUを使用できるかを示します。 より少ない交換で達成されて、セクション4.2.2で.1がそうであることが示されるようにネットからメディアがテーブルの上に置くIPの同じ縦断。
The SNMPv2 entity acting in a manager role begins by sending a GetBulkRequest-PDU with the modest max-repetitions value of 2, and containing the indicated OBJECT IDENTIFIER values as the requested variable names:
マネージャの役割で行動するSNMPv2実体は2の穏やかな最大反復値と、要求された変数名として示されたOBJECT IDENTIFIER値を含むのにGetBulkRequest-PDUを送ることによって、始まります:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
GetBulkRequest[非リピータは1、最大反復=2と等しいです](sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType)
SNMPv2 Working Group Standards Track [Page 16] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[16ページ]RFC1905プロトコル操作
The SNMPv2 entity acting in an agent role responds with a Response-PDU:
エージェントの役割で行動するSNMPv2実体はResponse-PDUと共に応じます:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
応答(sysUpTime.0=「123456」)、(ipNetToMediaPhysAddress、.1 .9 .2 .3 .4 =「000010543210」) (ipNetToMediaType.1.9.2.3.4=「動力」)、(ipNetToMediaPhysAddress.1.10.0.0.51=、「000010012345」)、(ipNetToMediaType.1.10.0.0.51=「静的」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
GetBulkRequest[非リピータは1、最大反復=2と等しいです](sysUpTime、ipNetToMediaPhysAddress、.1 .10 .0 .0 .51、ipNetToMediaType.1.10、.0、.0、.51)
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 =
"dynamic" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
応答(sysUpTime.0=「123466」)、(ipNetToMediaPhysAddress、.2 .10 .0 .0 .15 =「000010987654」) (ipNetToMediaType.2.10.0.0.15=「動力」)、(ipNetToMediaNetAddress.1.9.2.3.4=、「9.2 .3 0.4インチ)、(ipRoutingDiscards.0が等しい、「2インチ)」
This response signals the end of the table to the SNMPv2 entity acting in a manager role.
この応答はマネージャの役割で行動するSNMPv2実体にテーブルの端を示します。
4.2.4. The Response-PDU
4.2.4. 応答-PDU
The Response-PDU is generated by a SNMPv2 entity only upon receipt of a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this document.
Response-PDUは単にGetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、またはInformRequest-PDUを受け取り次第SNMPv2実体によって生成されます、ほかの場所で本書では説明されるように。
If the error-status field of the Response-PDU is non-zero, the value fields of the variable bindings in the variable binding list are ignored.
Response-PDUのエラー状況分野が非ゼロであるなら、変項束縛リストにおける変項束縛の値の分野は無視されます。
If both the error-status field and the error-index field of the Response-PDU are non-zero, then the value of the error-index field is the index of the variable binding (in the variable-binding list of the corresponding request) for which the request failed. The first variable binding in a request's variable-binding list is index one, the second is index two, etc.
エラー状況分野とResponse-PDUの誤りインデックス部の両方が非ゼロであるなら、誤りインデックス部の値は要求が失敗した変項束縛(対応する要求の変項束縛リストの)のインデックスです。 要求の変項束縛リストにおける最初の変項束縛がインデックス1である、2番目はインデックスtwoですなど。
SNMPv2 Working Group Standards Track [Page 17] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[17ページ]RFC1905プロトコル操作
A compliant SNMPv2 entity acting in a manager role must be able to properly receive and handle a Response-PDU with an error-status field equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2 of [8].)
マネージャの役割で行動する対応するSNMPv2実体は、適切に'noSuchName'、'badValue'、または'readOnly'と等しいエラー状況分野があるResponse-PDUを受けて、扱うことができなければなりません。 ([8]についてセクション3.1.2を見てください。)
Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents its contents to the SNMPv2 application which generated the request with the same request-id value.
Response-PDUを受け取り次第、受信SNMPv2実体は同じ要求イド値で要求を生成したSNMPv2アプリケーションにコンテンツを提示します。
4.2.5. The SetRequest-PDU
4.2.5. SetRequest-PDU
A SetRequest-PDU is generated and transmitted at the request of a SNMPv2 application.
SetRequest-PDUはSNMPv2アプリケーションの依頼で生成されて、伝えられます。
Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity determines the size of a message encapsulating a Response-PDU having the same values in its request-id and variable-bindings fields as the received SetRequest-PDU, and the largest possible sizes of the error-status and error-index fields. If the determined message size is greater than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU is generated, transmitted to the originator of the SetRequest-PDU, and processing of the SetRequest-PDU terminates immediately thereafter. This alternate Response-PDU is formatted with the same values in its request-id field as the received SetRequest-PDU, with the value of its error-status field set to `tooBig', the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the SetRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded. Regardless, processing of the SetRequest-PDU terminates.
SetRequest-PDUを受け取り次第、受信SNMPv2実体は容認されたSetRequest-PDUとしてその要求イドと変項束縛分野に同じ値を持っているResponse-PDUをカプセル化するメッセージのサイズ、およびエラー状況と誤りインデックス部の可能な限り大きいサイズを決定します。 決定しているメッセージサイズが創始者の地方の規制か最大のメッセージサイズのどちらかより大きいなら、代替のResponse-PDUはSetRequest-PDUの創始者に発生して、伝えられます、そして、SetRequest-PDUの処理はその後、すぐに、終わります。 この代替のResponse-PDUは容認されたSetRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない変項束縛分野で。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはSetRequest-PDUの創始者に伝えられます。 さもなければ、snmpSilentDrops[9]カウンタは増加されています、そして、結果のメッセージは捨てられます。 不注意に、SetRequest-PDUの処理は終わります。
Otherwise, the receiving SNMPv2 entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below.
さもなければ、受信SNMPv2実体は、Response-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response-PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。
The variable bindings are conceptually processed as a two phase operation. In the first phase, each variable binding is validated; if all validations are successful, then each variable is altered in the second phase. Of course, implementors are at liberty to implement either the first, or second, or both, of these conceptual phases as multiple implementation phases. Indeed, such multiple implementation phases may be necessary in some cases to ensure consistency.
変項束縛は二相操作として概念的に処理されます。 第1段階では、各変項束縛は有効にされます。 すべての合法化がうまくいくなら、各変数は2番目のフェーズで変更されます。 もちろん、作成者は複数の実施フェーズとしてこれらの概念的なフェーズの1番目2番目、または両方のどちらかを実装するのにおいて自由です。 本当に、そのような複数の実施フェーズが、いくつかの場合、一貫性があることを保証するのに必要であるかもしれません。
SNMPv2 Working Group Standards Track [Page 18] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[18ページ]RFC1905プロトコル操作
The following validations are performed in the first phase on each variable binding until they are all successful, or until one fails:
それらがすべてうまくいっているか、または1つが失敗するまで、以下の合法化は第1段階で各変項束縛に実行されます:
(1) If the variable binding's name specifies an existing or non-
existent variable to which this request is/would be denied access
because it is/would not be in the appropriate MIB view, then the
value of the Response-PDU's error-status field is set to
`noAccess', and the value of its error-index field is set to the
index of the failed variable binding.
(1) 変項束縛の名前が指定するなら、適切なMIB視点には/がないだろうということであるのでアクセスはこの要求が/である存在か非目下の変数に拒絶されるでしょう、そして、次に、Response-PDUのエラー状況分野の値は'noAccess'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(2) Otherwise, if there are no variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, and which are
able to be created or modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
(2) さもなければ、変項束縛の名前と同じOBJECT IDENTIFIER接頭語を共有して、作成するか、またはどんな新しい値が指定されても変更できるどんな変数もなければ、Response-PDUのエラー状況分野の値は'notWritable'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(3) Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a type which is inconsistent with
that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongType', and
the value of its error-index field is set to the index of the
failed variable binding.
(3) さもなければ、ASN.1言語によると、変項束縛の値の分野が指定するなら、それに矛盾したタイプが変項束縛の名前、次に、Response-PDUのエラー状況分野の値が'wrongType'に設定されて、誤りインデックス部の値が失敗した変項束縛のインデックスに設定されるときOBJECT IDENTIFIERが前に置く同じくらいを共有するすべての変数に必要です。
(4) Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a length which is inconsistent
with that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongLength', and
the value of its error-index field is set to the index of the
failed variable binding.
(4) さもなければ、ASN.1言語によると、変項束縛の値の分野が指定するなら、それに矛盾した長さが変項束縛の名前、次に、Response-PDUのエラー状況分野の値が'wrongLength'に設定されて、誤りインデックス部の値が失敗した変項束縛のインデックスに設定されるときOBJECT IDENTIFIERが前に置く同じくらいを共有するすべての変数に必要です。
(5) Otherwise, if the variable binding's value field contains an ASN.1
encoding which is inconsistent with that field's ASN.1 tag, then
the value of the Response-PDU's error-status field is set to
`wrongEncoding', and the value of its error-index field is set to
the index of the failed variable binding. (Note that not all
implementation strategies will generate this error.)
(5) さもなければ、変項束縛の値の分野がどれをコード化するかが矛盾しているフィールドのASN.1タグ、次に、Response-PDUのエラー状況分野の値が'wrongEncoding'に設定されて、誤りインデックス部の値が設定されるASN.1を含むなら、失敗した変項束縛のインデックスにセットしてください。 (すべての実装戦略がこの誤りを生成するというわけではないことに注意してください。)
(6) Otherwise, if the variable binding's value field specifies a value
which could under no circumstances be assigned to the variable,
then the value of the Response-PDU's error-status field is set to
`wrongValue', and the value of its error-index field is set to the
index of the failed variable binding.
(6) さもなければ、変項束縛の値の分野が変数に決して割り当てることができなかった値を指定するなら、Response-PDUのエラー状況分野の値は'wrongValue'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(7) Otherwise, if the variable binding's name specifies a variable
which does not exist and could not ever be created (even though
(7) さもなければ、変項束縛の名前が変数を指定するなら、どれが存在していなくて、またかつて作成されないかもしれないか、(
SNMPv2 Working Group Standards Track [Page 19] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[19ページ]RFC1905プロトコル操作
some variables sharing the same OBJECT IDENTIFIER prefix might
under some circumstances be able to be created), then the value of
the Response-PDU's error-status field is set to `noCreation', and
the value of its error-index field is set to the index of the
failed variable binding.
いくつかの変数、OBJECT IDENTIFIER接頭語がいくつかの状況でそうするかもしれない同じくらいを共有して、作成できてください、)、次に、Response-PDUのエラー状況分野の値は'noCreation'に設定されて、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(8) Otherwise, if the variable binding's name specifies a variable
which does not exist but can not be created under the present
circumstances (even though it could be created under other
circumstances), then the value of the Response-PDU's error-status
field is set to `inconsistentName', and the value of its error-
index field is set to the index of the failed variable binding.
(8) さもなければ、変項束縛の名前を存在しない変数を指定しますが、現在の情勢では作成できないなら(他の状況でそれを作成できるでしょうが)、Response-PDUのエラー状況分野の値は'inconsistentName'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(9) Otherwise, if the variable binding's name specifies a variable
which exists but can not be modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
(9) さもなければ、どんな新しい値が指定されても、変項束縛の名前を存在する変数を指定しますが、変更できないなら、Response-PDUのエラー状況分野の値は'notWritable'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(10) Otherwise, if the variable binding's value field specifies a value
that could under other circumstances be held by the variable, but
is presently inconsistent or otherwise unable to be assigned to the
variable, then the value of the Response-PDU's error-status field
is set to `inconsistentValue', and the value of its error-index
field is set to the index of the failed variable binding.
(10) さもなければ、変項束縛の値の分野が変数で他の状況で保持できるでしょうが、現在、矛盾しているか、またはそうでなければ変数に割り当てることができない値を指定するなら、Response-PDUのエラー状況分野の値は'inconsistentValue'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(11) When, during the above steps, the assignment of the value specified
by the variable binding's value field to the specified variable
requires the allocation of a resource which is presently
unavailable, then the value of the Response-PDU's error-status
field is set to `resourceUnavailable', and the value of its error-
index field is set to the index of the failed variable binding.
(11) 変項束縛の値の分野によって指定された変数に指定された価値の課題が上のステップの間、現在入手できないリソースの配分を必要とすると、Response-PDUのエラー状況分野の値は'resourceUnavailable'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(12) If the processing of the variable binding fails for a reason other
than listed above, then the value of the Response-PDU's error-
status field is set to `genErr', and the value of its error-index
field is set to the index of the failed variable binding.
(12) 変項束縛の処理が上に記載されているのを除いた理由で失敗するなら、Response-PDU誤りの状態分野の値は'genErr'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(13) Otherwise, the validation of the variable binding succeeds.
(13) さもなければ、変項束縛の合法化は成功します。
At the end of the first phase, if the validation of all variable bindings succeeded, then the value of the Response-PDU's error-status field is set to `noError' and the value of its error-index field is zero, and processing continues as follows.
第1段階の終わりでは、すべての変項束縛の合法化が成功したなら、Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです、そして、処理は以下の通り続きます。
For each variable binding in the request, the named variable is created if necessary, and the specified value is assigned to it. Each of these variable assignments occurs as if simultaneously with
必要なら、要求における各変項束縛において、名前付き変数は作成されます、そして、規定値はそれに割り当てられます。 それぞれのこれらの可変課題はまるで同時であるかのように起こります。
SNMPv2 Working Group Standards Track [Page 20] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[20ページ]RFC1905プロトコル操作
respect to all other assignments specified in the same request. However, if the same variable is named more than once in a single request, with different associated values, then the actual assignment made to that variable is implementation-specific.
他のすべての課題への敬意は同じ要求で指定しました。 しかしながら、同じ変数が異なった関連値があるただ一つの要求の一度よりもう少し命名されるなら、その変数までされた実際の課題は実装特有です。
If any of these assignments fail (even after all the previous validations), then all other assignments are undone, and the Response-PDU is modified to have the value of its error-status field set to `commitFailed', and the value of its error-index field set to the index of the failed variable binding.
これらの課題のどれかが失敗するなら(前のすべての合法化の後にさえ)、他のすべての課題が元に戻されました、そして、Response-PDUは'commitFailed'にエラー状況分野の値を設定させるように変更されました、そして、誤りインデックス部の値は失敗した変項束縛のインデックスにセットしました。
If and only if it is not possible to undo all the assignments, then the Response-PDU is modified to have the value of its error-status field set to `undoFailed', and the value of its error-index field is set to zero. Note that implementations are strongly encouraged to take all possible measures to avoid use of either `commitFailed' or `undoFailed' - these two error-status codes are not to be taken as license to take the easy way out in an implementation.
そして、すべての課題を元に戻すのが可能でない場合にだけ、Response-PDUは'undoFailed'にエラー状況分野の値を設定させるように変更されて、誤りインデックス部の値はゼロに設定されます。 実装が'commitFailed'か'undoFailed'のどちらかの使用を避けるすべての可能な対策を実施するよう強く奨励されることに注意してください--これらの2つのエラー状況コードは実装で簡単なやり方を見つけるライセンスとして取られないことです。
Finally, the generated Response-PDU is encapsulated into a message, and transmitted to the originator of the SetRequest-PDU.
最終的に、発生しているResponse-PDUはメッセージにカプセル化されて、SetRequest-PDUの創始者に伝えられます。
4.2.6. The SNMPv2-Trap-PDU
4.2.6. SNMPv2はPDUを捕らえます。
A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity acting in an agent role when an exceptional situation occurs.
SNMPv2罠PDUは例外的な状況が起こるとエージェントの役割で行動するSNMPv2実体によって、生成されて、伝えられます。
The destination(s) to which a SNMPv2-Trap-PDU is sent is determined in an implementation-dependent fashion by the SNMPv2 entity. The first two variable bindings in the variable binding list of an SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMPv2 entity), then each is copied to the variable-bindings field.
SNMPv2罠PDUが送られる目的地はSNMPv2実体で実装依存するファッションで決定します。 SNMPv2罠PDUの変項束縛リストにおける最初の2つの変項束縛が、それぞれsysUpTime.0[9]とsnmpTrapOID.0[9]です。 OBJECTS節が対応するNOTIFICATION-TYPEマクロの実施で存在しているなら、この通知で例示されるそれぞれの対応する変数はコピーされます、オーダーで、変項束縛分野に。 何か追加変数が含まれているなら(生成しているSNMPv2実体の選択のときに)、それぞれが変項束縛分野にコピーされます。
4.2.7. The InformRequest-PDU
4.2.7. InformRequest-PDU
An InformRequest-PDU is generated and transmitted at the request of an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (in a SNMPv2 entity also acting in a manager role) of information in a MIB view which is remote to the receiving application.
InformRequest-PDUはマネージャの役割で行動するSNMPv2実体におけるアプリケーションの依頼で生成されて、伝えられて、それは受信アプリケーションにリモートなMIB視点における、情報の別のアプリケーション(また、マネージャの役割で行動するSNMPv2実体における)に通知したがっています。
The destination(s) to which an InformRequest-PDU is sent is specified by the requesting application. The first two variable bindings in
InformRequest-PDUが送られる目的地は要求アプリケーションで指定されます。 中の最初の2つの変項束縛
SNMPv2 Working Group Standards Track [Page 21] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[21ページ]RFC1905プロトコル操作
the variable binding list of an InformRequest-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field.
InformRequest-PDUの変項束縛リストは、それぞれsysUpTime.0[9]とsnmpTrapOID.0[9]です。 OBJECTS節が対応するNOTIFICATION-TYPEマクロの実施で存在しているなら、この通知で例示されるそれぞれの対応する変数はコピーされます、オーダーで、変項束縛分野に。
Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity determines the size of a message encapsulating a Response-PDU with the same values in its request-id, error-status, error-index and variable-bindings fields as the received InformRequest-PDU. If the determined message size is greater than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU is generated, transmitted to the originator of the InformRequest-PDU, and processing of the InformRequest-PDU terminates immediately thereafter. This alternate Response-PDU is formatted with the same values in its request-id field as the received InformRequest-PDU, with the value of its error-status field set to `tooBig', the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the InformRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is incremented and the resultant message is discarded. Regardless, processing of the InformRequest-PDU terminates.
InformRequest-PDUを受け取り次第、受信SNMPv2実体は同じ値が要求イドにある状態でResponse-PDUをカプセル化するメッセージのサイズを決定します、エラー状況、容認されたInformRequest-PDUとしての誤りインデックスと変項束縛分野。 決定しているメッセージサイズが創始者の地方の規制か最大のメッセージサイズのどちらかより大きいなら、代替のResponse-PDUはInformRequest-PDUの創始者に発生して、伝えられます、そして、InformRequest-PDUの処理はその後、すぐに、終わります。 この代替のResponse-PDUは容認されたInformRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない変項束縛分野で。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と創始者の最大のメッセージサイズであるなら、それはInformRequest-PDUの創始者に伝えられます。 さもなければ、snmpSilentDrops[9]カウンタは増加されています、そして、結果のメッセージは捨てられます。 不注意に、InformRequest-PDUの処理は終わります。
Otherwise, the receiving SNMPv2 entity:
そうでなければ、受信SNMPv2実体:
(1) presents its contents to the appropriate SNMPv2 application;
(1) 適切なSNMPv2アプリケーションにコンテンツを提示します。
(2) generates a Response-PDU with the same values in its request-id and
variable-bindings fields as the received InformRequest-PDU, with
the value of its error-status field is set to `noError' and the
value of its error-index field is zero; and
(2) 同じ値がその要求イドと変項束縛分野にある状態で、容認されたInformRequest-PDU、エラー状況の値で、分野が'noError'に設定されて、誤りインデックス部の値がゼロであるので、Response-PDUを生成します。 そして
(3) transmits the generated Response-PDU to the originator of the
InformRequest-PDU.
(3) 発生しているResponse-PDUをInformRequest-PDUの創始者に伝えます。
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
SNMPv2 Working Group Standards Track [Page 22] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[22ページ]RFC1905プロトコル操作
6. Editor's Address
6. エディタのアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 526 5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1 5260年の408 526メール: kzm@cisco.com
7. Acknowledgements
7. 承認
This document is the result of significant work by the four major contributors:
このドキュメントは4人の一流の貢献者による重要な仕事の結果です:
Jeffrey D. Case (SNMP Research, case@snmp.com) Keith McCloghrie (Cisco Systems, kzm@cisco.com) Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) Steven Waldbusser (International Network Services, stevew@uni.ins.com)
ジェフリーD.事件(SNMP研究、 case@snmp.com )キースMcCloghrie(シスコシステムズ、 kzm@cisco.com )マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング、 mrose@dbc.mtview.ca.us )スティーブンWaldbusser(国際ネットワークサービス、 stevew@uni.ins.com )
In addition, the contributions of the SNMPv2 Working Group are acknowledged. In particular, a special thanks is extended for the contributions of:
さらに、SNMPv2作業部会の貢献は承諾されます。 特に、以下の貢献のために特別な感謝を表します。
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
アレクサンダーI; アルテン(ノベル)デーヴArneson(Cabletron)ユリ・ブルーメンソル(IBM)ダグBook(Chipcom)キム・カラン(ベル-北研究)・ジム・ガルビン(情報システムを信じる)・マリア・グリーン(Ascom Timeplex)イアンハンソン(デジタル)のデーヴ・ハリントン(Cabletron)Nguyen Hien(IBM)ジェフ・ジョンソン(シスコシステムズ)マイケルKornegay; (オブジェクト探索) ディアドラKostick(AT&Tベル研究所)デヴィッド・レビ(SNMP研究)・ダニエル・マホニー(Cabletron)ボブNatale(ACE*COMM)ブライアン・オキーフ(ヒューレットパッカード)アンドリューピアソン(SNMP研究)のデーヴ・パーキンス(同輩ネットワーク)ランディPresuhn(同輩ネットワーク)アレックセイ・ロマーノフ(上質の定足数)ショーンRouthier(エピローグ)ジョンSaperia(BGSシステム)
SNMPv2 Working Group Standards Track [Page 23] RFC 1905 Protocol Operations for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[23ページ]RFC1905プロトコル操作
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)
ボブ・スチュワート(シスコシステムズ、 bstewart@cisco.com )、いすカイTesink(Bellcore)グレンWaters(ベル-北Research)バートWijnen(IBM)
8. References
8. 参照
[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[1] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[3]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[4] Kent, C., and J. Mogul, Fragmentation Considered Harmful,
Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
[4] ケント、C.とJ.ムガール人、有害であると考えられた断片化、議事、ACM SIGCOMM87年、ストウ、バーモント(1987年8月)。
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[5]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[6] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[7] McCloghrie, K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets:
MIB-II", STD 17, RFC 1213, March 1991.
[7] McCloghrie、K.とM.ローズ、エディターズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Coexistence between Version 1 and Version 2
of the Internet-standard Network Management Framework", RFC 1908,
January 1996.
[8]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」、RFC1908(1996年1月)。
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
[9]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。
SNMPv2 Working Group Standards Track [Page 24]
SNMPv2ワーキンググループ標準化過程[24ページ]
一覧
スポンサーリンク
