RFC2257 日本語訳
2257 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B.Wijnen, D. Francisco. January 1998. (Format: TXT=177452 bytes) (Obsoleted by RFC2741) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Daniele
Request for Comments: 2257 Digital Equipment Corporation
Category: Standards Track B. Wijnen
T.J. Watson Research Center, IBM Corp.
D. Francisco, Ed.
Cisco Systems, Inc.
January 1998
コメントを求めるワーキンググループM.ダニエル要求をネットワークでつないでください: 2257年のDECカテゴリ: 規格は1998年1月にエドB.Wijnen T.J.ワトソン研究所、IBM社のD.フランシスコ、シスコシステムズInc.を追跡します。
Agent Extensibility (AgentX) Protocol
Version 1
エージェント伸展性(AgentX)プロトコルバージョン1
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1 Introduction......................................................4
1つの序論…4
2 The SNMP Framework................................................4
2.1 A Note on Terminology.........................................4
2 SNMPフレームワーク…4 2.1 用語に関する注…4
3 Extending the MIB.................................................5
3.1 Motivation for AgentX.........................................5
3 MIBを広げています…5 AgentXに関する3.1動機…5
4 AgentX Framework..................................................6
4.1 AgentX Roles..................................................7
4.2 Applicability.................................................8
4.3 Design Features of AgentX.....................................9
4.4 Non-Goals....................................................10
4AgentXフレームワーク…6 4.1 AgentXの役割…7 4.2の適用性…8 4.3 AgentXの特徴を設計してください…9 4.4 非目標…10
5 AgentX Encodings.................................................10
5.1 Object Identifier............................................11
5.2 SearchRange..................................................13
5.3 Octet String.................................................14
5.4 Value Representation.........................................14
5AgentX Encodings…10 5.1オブジェクト識別子…11 5.2SearchRange…13 5.3八重奏ストリング…14 5.4 表現を評価してください…14
6 Protocol Definitions.............................................16
6.1 AgentX PDU Header............................................16
6 定義について議定書の中で述べてください…16 6.1AgentX PDUヘッダー…16
Daniele, et. al. Standards Track [Page 1] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[1ページ]。
6.1.1 Context..................................................19
6.2 AgentX PDUs..................................................20
6.2.1 The agentx-Open-PDU......................................20
6.2.2 The agentx-Close-PDU.....................................21
6.2.3 The agentx-Register-PDU..................................22
6.2.4 The agentx-Unregister-PDU................................25
6.2.5 The agentx-Get-PDU.......................................27
6.2.6 The agentx-GetNext-PDU...................................29
6.2.7 The agentx-GetBulk-PDU...................................30
6.2.8 The agentx-TestSet-PDU...................................31
6.2.9 The agentx-CommitSet, -UndoSet, -CleanupSet
PDUs.....................................................33
6.2.10 The agentx-Notify-PDU...................................33
6.2.11 The agentx-Ping-PDU.....................................34
6.2.12 The agentx-IndexAllocate-PDU............................35
6.2.13 The agentx-IndexDeallocate-PDU..........................36
6.2.14 The agentx-AddAgentCaps-PDU.............................37
6.2.15 The agentx-RemoveAgentCaps-PDU..........................38
6.2.16 The agentx-Response-PDU.................................39
6.1.1 文脈…19 6.2AgentX PDUs…20 6.2 .1 agentxの開いているPDU…20 6.2 .2 agentxの近いPDU…21 6.2 .3 agentxレジスタPDU…22 6.2 .4 agentx-Unregister-PDU…25 6.2 .5 agentxはPDUを手に入れます…27 6.2 .6 agentx-GetNext-PDU…29 6.2 .7 agentx-GetBulk-PDU…30 6.2 .8 agentx-TestSet-PDU…31 6.2 .9、agentx-CommitSet、-UndoSet、-CleanupSet PDUs…33 6.2 .10 agentxはPDUに通知しています…33 6.2 .11 agentxピングPDU…34 6.2 .12 agentx-IndexAllocate-PDU…35 6.2 .13 agentx-IndexDeallocate-PDU…36 6.2 .14 agentx-AddAgentCaps-PDU…37 6.2 .15 agentx-RemoveAgentCaps-PDU…38 6.2 .16 agentx応答PDU…39
7 Elements of Procedure............................................41
7.1 Processing AgentX Administrative Messages....................42
7.1.1 Processing the agentx-Open-PDU...........................42
7.1.2 Processing the agentx-IndexAllocate-PDU..................43
7.1.3 Using the agentx-IndexAllocate-PDU.......................45
7.1.4 Processing the agentx-IndexDeallocate-PDU................47
7.1.5 Processing the agentx-Register-PDU.......................48
7.1.5.1 Handling Duplicate OID Ranges........................50
7.1.6 Processing the agentx-Unregister-PDU.....................51
7.1.7 Processing the agentx-AddAgentCaps-PDU...................51
7.1.8 Processing the agentx-RemoveAgentCaps-PDU................52
7.1.9 Processing the agentx-Close-PDU..........................52
7.1.10 Detecting Connection Loss...............................53
7.1.11 Processing the agentx-Notify-PDU........................53
7.1.12 Processing the agentx-Ping-PDU..........................54
7.2 Processing Received SNMP Protocol Messages...................54
7.2.1 Dispatching AgentX PDUs..................................55
7.2.1.1 agentx-Get-PDU.......................................57
7.2.1.2 agentx-GetNext-PDU...................................58
7.2.1.3 agentx-GetBulk-PDU...................................59
7.2.1.4 agentx-TestSet-PDU...................................60
7.2.1.5 Dispatch.............................................60
7.2.2 Subagent Processing of agentx-Get, GetNext,
GetBulk-PDUs.............................................61
7.2.2.1 Subagent Processing of the agentx-Get-PDU............61
7.2.2.2 Subagent Processing of the
agentx-GetNext-PDU...................................62
7 手順のElements…41 7.1 処理のAgentXの管理メッセージ…42 7.1 .1 agentxの開いているPDUを処理します…42 7.1 .2 agentx-IndexAllocate-PDUを処理します…43 7.1 .3 agentx-IndexAllocate-PDUを使用します…45 7.1 .4 agentx-IndexDeallocate-PDUを処理します…47 7.1 .5 agentxレジスタPDUを処理します…48 7.1 .5 .1 取り扱い写しOIDは及びます…50 7.1 .6 agentx-Unregister-PDUを処理します…51 7.1 .7 agentx-AddAgentCaps-PDUを処理します…51 7.1 .8 agentx-RemoveAgentCaps-PDUを処理します…52 7.1 .9 agentxの近いPDUを処理します…52 7.1 .10 接続の損失を検出します…53 7.1 .11 agentxにPDUに通知しているのを処理します…53 7.1 .12 agentxピングPDUを処理します…54 7.2 処理はSNMPプロトコルメッセージを受け取りました…54 7.2 .1 AgentX PDUsを派遣します…55 7.2 .1 .1 agentxはPDUを手に入れます…57 7.2 .1 .2agentx-GetNext-PDU…58 7.2 .1 .3agentx-GetBulk-PDU…59 7.2 .1 .4agentx-TestSet-PDU…60 7.2 .1 .5 急いでください…60 agentx得るのを処理する7.2.2副代理店、GetNext、GetBulk-PDUs… …61 7.2 .2 .1 agentxがPDUを手に入れることの副代理店処理…61 7.2 .2 .2 agentx-GetNext-PDUの副代理店処理…62
Daniele, et. al. Standards Track [Page 2] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[2ページ]。
7.2.2.3 Subagent Processing of the
agentx-GetBulk-PDU...................................62
7.2.3 Subagent Processing of agentx-TestSet,
-CommitSet, -UndoSet, -CleanupSet-PDUs...................63
7.2.3.1 Subagent Processing of the
agentx-TestSet-PDU...................................64
7.2.3.2 Subagent Processing of the
agentx-CommitSet-PDU.................................65
7.2.3.3 Subagent Processing of the
agentx-UndoSet-PDU...................................65
7.2.3.4 Subagent Processing of the
agentx-CleanupSet-PDU................................65
7.2.4 Master Agent Processing of AgentX Responses..............66
7.2.4.1 Common Processing of All AgentX Response
PDUs.................................................66
7.2.4.2 Processing of Responses to agentx-Get-PDUs...........66
7.2.4.3 Processing of Responses to
agentx-GetNext-PDU and agentx-GetBulk-PDU............67
7.2.4.4 Processing of Responses to
agentx-TestSet-PDUs..................................68
7.2.4.5 Processing of Responses to
agentx-CommitSet-PDUs................................68
7.2.4.6 Processing of Responses to
agentx-UndoSet-PDUs..................................69
7.2.5 Sending the SNMP Response-PDU............................69
7.2.6 MIB Views................................................69
7.3 State Transitions............................................70
7.3.1 Set Transaction States...................................70
7.3.2 Transport Connection States..............................71
7.3.3 Session States...........................................73
7.2.2.3 agentx-GetBulk-PDUの副代理店処理…62 7.2 .3 agentx-TestSet、-CommitSet、-UndoSet、-CleanupSet-PDUsの副代理店処理…63 7.2 .3 .1 agentx-TestSet-PDUの副代理店処理…64 7.2 .3 .2 agentx-CommitSet-PDUの副代理店処理…65 7.2 .3 .3 agentx-UndoSet-PDUの副代理店処理…65 7.2 .3 .4 agentx-CleanupSet-PDUの副代理店処理…65 7.2 .4 AgentX応答の処理をエージェントにマスタリングしてください…66 7.2 .4 .1 すべてのAgentX応答PDUsの一般的な処理…66 7.2 .4 .2 agentxがPDUsを手に入れることへの応答の処理…66 7.2 .4 .3 agentx-GetNext-PDUとagentx-GetBulk-PDUへの応答の処理…67 7.2 .4 .4 agentx-TestSet-PDUsへの応答の処理…68 7.2 .4 .5 agentx-CommitSet-PDUsへの応答の処理…68 7.2 .4 .6 agentx-UndoSet-PDUsへの応答の処理…69 7.2 .5 SNMP応答-PDUを送ります…69 7.2 .6 MIB視点…69 7.3 変遷を述べてください…70 7.3 .1 トランザクション州を設定してください…70 7.3 .2 接続州を輸送してください…71 7.3 .3 セッション州…73
8 Transport Mappings...............................................74
8.1 AgentX over TCP..............................................74
8.1.1 Well-known Values........................................74
8.1.2 Operation................................................74
8.2 AgentX over UNIX-domain Sockets..............................75
8.2.1 Well-known Values........................................75
8.2.2 Operation................................................75
8 マッピングを輸送してください…74 TCPの上の8.1AgentX…74 8.1 .1 よく知られる値…74 8.1 .2操作…74 8.2 UNIX-ドメインの上のAgentXソケット…75 8.2 .1 よく知られる値…75 8.2 .2操作…75
9 Security Considerations..........................................76
9 セキュリティ問題…76
10 Acknowledgements................................................77
10の承認…77
11 Authors' and Editor's Addresses.................................77
11人の作者とエディタのアドレス…77
12 References......................................................78
12の参照箇所…78
13 Full Copyright Statement........................................80
13 完全な著作権宣言文…80
Daniele, et. al. Standards Track [Page 3] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[3ページ]。
1. Introduction
1. 序論
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages.
このメモは広げることができるSNMPエージェントのために標準化されたフレームワークを定義します。 プロトコル(AgentX)は、以前はそれらと、手順の要素の広げることができるエージェントがSNMPプロトコルメッセージを処理する間でよくそれがマスターエージェントと副代理店と呼ばれる処理実体を定義すると伝えていました。
2. The SNMP Framework
2. SNMPフレームワーク
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) (see RFC 1902 [2]).
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 Management情報(SMI)のStructureは、これらのモジュールがOSIの抽象的なSyntax Notation One(ASN.1)[1]の部分集合を使用することで書かれていると呼びました。(RFC1902[2])を見てください。
2.1. A Note on Terminology
2.1. 用語に関する注
The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI (RFC 1902, [2]) or the textual conventions based on the SMI (RFC 1903 [3]). The term "variable binding" normally refers to the pairing of the name of a variable and 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.
RFC1902、[2])または原文のコンベンションがSMIを基礎づけました。「可変である」という用語がSMIに詳しく説明されたコンベンションに従って定義された非集団オブジェクトタイプのインスタンスについて言及する、((RFC1903[3])。 通常、「変項束縛」という用語は可変価値とその関連価値の名前の組み合わせについて言及します。 しかしながら、ある種類の例外的な状態が検索要求の処理の間、現れると、変項束縛はその例外の名前としるしを対にするでしょう。
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
変数の名前はOBJECT IDENTIFIERです。(OBJECT IDENTIFIER断片同一視と共にそのOBJECT IDENTIFIERは対応するオブジェクト・タイプのOBJECT IDENTIFIERの連結です)。
Daniele, et. al. Standards Track [Page 4] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[4ページ]。
instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable. For the purpose of exposition, the original Internet-standard
インスタンス。 対応するオブジェクト・タイプのOBJECT IDENTIFIERは変数のOBJECT IDENTIFIER接頭語と呼ばれます。 博覧会の目的、元のインターネット標準のために
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, as described in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2).
RFCs1155(STD16)、1157年(STD15)、および1212年(STD16)に説明されるネットワークManagement FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 RFCs1902-1908で説明される現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
3. Extending the MIB
3. MIBを広げています。
New MIB modules that extend the Internet-standard MIB are continuously being defined by various IETF working groups. It is also common for enterprises or individuals to create or extend enterprise-specific or experimental MIBs.
インターネット標準MIBを広げる新しいMIBモジュールが様々なIETFワーキンググループによって絶え間なく定義されています。 また、企業か個人が企業特有の、または、実験的なMIBsを作成するか、または広げるのも、一般的です。
As a result, managed devices are frequently complex collections of manageable components that have been independently installed on a managed node. Each component provides instrumentation for the managed objects defined in the MIB module(s) it implements.
その結果、管理されたデバイスは独自に管理されたノードにインストールされた処理しやすいコンポーネントの頻繁に複雑な収集です。 各コンポーネントはそれが実装するMIBモジュールで定義された管理オブジェクトのための計装を提供します。
Neither the SNMP version 1 nor version 2 framework describes how the set of managed objects supported by a particular agent may be changed dynamically.
SNMPバージョン1もバージョン2フレームワークもどうダイナミックに特定代理人によってサポートされた管理オブジェクトのセットを変えるかもしれないかを説明しません。
3.1. Motivation for AgentX
3.1. AgentXに関する動機
This very real need to dynamically extend the management objects within a node has given rise to a variety of "extensible agents", which typically comprise
ノードの中でダイナミックに管理オブジェクトを広げるこの非常に本当の必要性がさまざまな「広げることができるエージェント」をもたらした、どれ、通常包括するか。
- a "master" agent that is available on the standard transport
address and that accepts SNMP protocol messages
- 標準の輸送アドレスで利用可能であり、SNMPプロトコルメッセージを受け入れる「マスター」エージェント
- a set of "subagents" that each contain management
instrumentation
- それぞれ管理計装を含む1セットの「副代理店」
- a protocol that operates between the master agent and subagents,
permitting subagents to "connect" to the master agent, and the
master agent to multiplex received SNMP protocol messages
amongst the subagents.
- マスターエージェントと副代理店の間で作動するプロトコル、マスターエージェント、およびマスターエージェントへの「接続してください」への副代理店が多重送信されることを許可するのがSNMPプロトコルメッセージを副代理店に受け取りました。
- a set of tools to aid subagent development, and a runtime (API)
environment that hides much of the protocol operation between a
subagent and the master agent.
- 副代理店開発を支援するツール、およびたくさん隠す副代理店とマスターエージェントの間のプロトコル操作のランタイム(API)環境の1セット。
Daniele, et. al. Standards Track [Page 5] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[5ページ]。
The wide deployment of extensible SNMP agents, coupled with the lack of Internet standards in this area, makes it difficult to field SNMP-manageable applications. A vendor may have to support several different subagent environments (APIs) in order to support different target platforms.
この領域における、インターネット標準の不足に結びつけられた広げることができるSNMPエージェントの広い展開で、SNMP処理しやすいアプリケーションをさばくのは難しくなります。 ベンダーは、異なった目標プラットホームをサポートするためにいくつかの異なった副代理店環境が(API)であるとサポートしなければならないかもしれません。
It can also become quite cumbersome to configure subagents and (possibly multiple) master agents on a particular managed node.
また、特定の管理されたノードの上の副代理店と(ことによると複数)のマスターエージェントを構成するのはかなり厄介になることができます。
Specifying a standard protocol for agent extensibility (AgentX) provides the technical foundation required to solve both of these problems. Independently developed AgentX-capable master agents and subagents will be able to interoperate at the protocol level. Vendors can continue to differentiate their products in all other respects.
エージェント伸展性(AgentX)に標準プロトコルを指定すると、これらの問題の両方を解決するのに必要である技術的な基礎を提供します。独自に開発されたAgentX有能なマスターエージェントと副代理店はプロトコルレベルで共同利用できるでしょう。 ベンダーは、他のすべての点でそれらの製品を差別化し続けることができます。
4. AgentX Framework
4. AgentXフレームワーク
Within the SNMP framework, a managed node contains a processing entity, called an agent, which has access to management information.
SNMPフレームワークの中では、管理されたノードは経営情報に近づく手段を持っているエージェントと呼ばれる処理実体を含みます。
Within the AgentX framework, an agent is further defined to consist of
AgentXフレームワークの中では、エージェントは成るように定義されていた状態で、より遠いです。
- a single processing entity called the master agent, which sends
and receives SNMP protocol messages in an agent role (as
specified by the SNMP version 1 and version 2 framework
documents) but typically has little or no direct access to
management information.
- マスターエージェントと呼ばれるただ一つの処理実体はまず経営情報に直接アクセスをエージェントの役割(SNMPバージョン1とバージョン2フレームワークドキュメントによって指定されるように)、しかし、通常持っていません。そのエージェントは、SNMPプロトコルメッセージを送って、受け取ります。
- 0 or more processing entities called subagents, which are
"shielded" from the SNMP protocol messages processed by the
master agent, but which have access to management information.
- 0つ以上の処理実体が、副代理店と呼びました。(マスターエージェントによって処理されたSNMPプロトコルメッセージから「保護されます」が、副代理店は経営情報に近づく手段を持っています)。
The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. Other interfaces (if any) on these entities, and their associated protocols, are outside the scope of this document. While some of the AgentX protocol messages appear similar in syntax and semantics to the SNMP, bear in mind that AgentX is not SNMP.
マスターと副代理店実体はこのメモで指定されるようにAgentXプロトコルメッセージで交信します。 このドキュメントの範囲の外にこれらの実体、およびそれらの関連プロトコルの他のインタフェース(もしあれば)があります。 AgentXプロトコルメッセージのいくつかが構文と意味論においてSNMPと同様に見えている間、AgentXがSNMPでないことを覚えておいてください。
The internal operations of AgentX are invisible to an SNMP entity operating in a manager role. From a manager's point of view, an extensible agent behaves exactly as would a non-extensible (monolithic) agent that has access to the same management instrumentation.
AgentXの社内業務はマネージャの役割で作動するSNMP実体に目に見えません。 マネージャの観点から、広げることができるエージェントはちょうど同じ管理計装に近づく手段を持っている非広げることができる(一枚岩的な)エージェントであるだろうことのように振る舞います。
Daniele, et. al. Standards Track [Page 6] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[6ページ]。
This transparency to managers is a fundamental requirement of AgentX, and is what differentiates AgentX subagents from SNMP proxy agents.
マネージャへのこの透明は、AgentXの基本的な要件であり、SNMPプロキシエージェントとAgentX副代理店を区別することです。
4.1. AgentX Roles
4.1. AgentXの役割
An entity acting in a master agent role performs the following functions:
マスターエージェントの役割で行動する実体は以下の機能を実行します:
- Accepts AgentX session establishment requests from subagents.
- 副代理店からAgentXセッション設立要求を受け入れます。
- Accepts registration of MIB regions by subagents.
- 副代理店はMIB領域の登録を受け入れます。
- Sends and accepts SNMP protocol messages on the agent's
specified transport addresses.
- エージェントの指定された輸送アドレスに関するSNMPプロトコルメッセージを送って、受け入れます。
- Implements the agent role Elements of Procedure specified
for the administrative framework applicable to the SNMP protocol
message, except where they specify performing management
operations. (The application of MIB views, and the access
control policy for the managed node, are implemented by the
master agent.)
- エージェントの役割が管理操作を実行する彼らが指定するところ以外のSNMPプロトコルメッセージに適切な管理フレームワークに指定されたProcedureのElementsであると実装します。 (MIB視点のアプリケーションと、管理されたノードのためのアクセス制御政策はマスターエージェントによって実施されます。)
- Provides instrumentation for the MIB objects defined in RFC
1907 [5], and for any MIB objects relevant to any administrative
framework it supports.
- RFC1907[5]で定義されたMIBオブジェクト、およびそれがサポートするどんな管理フレームワークにも関連しているどんなMIBオブジェクトのための計装も提供します。
- Sends and receives AgentX protocol messages to access
management information, based on the current registry of MIB
regions.
- MIB領域の現在の登録に基づいて経営情報にアクセスするAgentXプロトコルメッセージを送って、受け取ります。
- Forwards notifications on behalf of subagents.
- 副代理店を代表して通知を転送します。
An entity acting in a subagent role performs the following functions:
副代理店の役割で行動する実体は以下の機能を実行します:
- Initiates an AgentX session with the master agent.
- マスターエージェントとのAgentXセッションを開始します。
- Registers MIB regions with the master agent.
- マスターエージェントにMIB領域を登録します。
- Instantiates managed objects.
- 管理オブジェクトを例示します。
- Binds OIDs within its registered MIB regions to actual
variables.
- 実際の変数への登録されたMIB領域の中のひものOIDs。
- Performs management operations on variables.
- 変数に管理操作を実行します。
- Initiates notifications.
- 通知を開始します。
Daniele, et. al. Standards Track [Page 7] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[7ページ]。
4.2 Applicability
4.2 適用性
It is intended that this memo specify the smallest amount of required behavior necessary to achieve the largest benefit, that is, to cover a very large number of possible MIB implementations and configurations with minimum complexity and low "cost of entry".
このメモが最も大きい利益を達成するのに必要な必要な振舞いの最小量を指定することを意図して、最小の複雑さがある可能なMIB実装と非常に多くの構成と低い「エントリーの費用」をカバーするために、それはいます。
This section discusses several typical usage scenarios.
このセクションはいくつかの典型的な用法シナリオについて論じます。
1) Subagents implement separate MIB modules--for example,
subagent A implements "mib-2", subagent b implements "host-
resources".
1) 副代理店は別々のMIBモジュールを実装します--例えば、「何mib-2インチも、副代理店bは「ホストリソース」を実装する」副代理店A道具。
It is anticipated that this will be the most common subagent
configuration.
これが最も一般的な副代理店構成になると予期されます。
2) Subagents implement rows in a "simple table". A simple table
is one in which row creation is not specified, and for which the
MIB does not define an object that counts entries in the table.
Examples of simple tables are rdbmsDbTable, udpTable, and
hrSWRunTable.
2) 副代理店は「単純分類表」の行を実装します。 単純分類表はテーブルの行作成が指定されないで、またMIBがエントリーを数えるオブジェクトを定義しないものです。 単純分類表に関する例は、rdbmsDbTableと、udpTableと、hrSWRunTableです。
This is the most commonly defined type of MIB table, and probably
represents the next most typical configuration that AgentX would
support.
これは、最も一般的に定義されたタイプのMIBテーブルであり、たぶん、次のAgentXがサポートする中で最も典型的な構成を表します。
3) Subagents share MIBs along non-row partitions. Subagents
register "chunks" of the MIB that represent multiple rows, due to
the nature of the MIB's index structure. Examples include
registering ipNetToMediaEntry.n, where n represents the ifIndex
value for an interface implemented by the subagent, and
tcpConnEntry.a.b.c.d, where a.b.c.d represents an IP address on an
interface implemented by the subagent.
3) 副代理店は非行パーティションに沿ってMIBsを共有します。 副代理店はMIBのインデックス構造の本質のため複数の行を表すMIBの「塊」を登録します。 例は、ipNetToMediaEntry.n、およびtcpConnEntry.a.b.c.dを登録するのを含んでいます。そこでは、nが副代理店によって実装されたインタフェースにifIndex値を表します。(そこでは、a.b.c.dは副代理店によって実装されたインタフェースに関するIPアドレスを表します)。
AgentX supports these three common configurations, and all permutations of them, completely. The consensus is that they comprise a very large majority of current and likely future uses of multi-vendor extensible agent configurations.
AgentXは、これらが3つの一般的な構成と、それらの全順列であると完全にサポートします。 コンセンサスは彼らがマルチベンダの広げることができるエージェント構成の現在の、そして、ありそうな将来の用途の非常に大きい大部分を包括するということです。
4) Subagents implement rows in "complex tables". Complex tables
here are defined as tables permitting row creation, or whose MIB
also defines an object that counts entries in the table. Examples
include the MIB-2 ifTable (due to ifNumber), and the RMON
historyControlTable.
4) 副代理店は「複雑なテーブル」の行を実装します。 ここの複雑なテーブルは行作成を可能にするテーブルと定義されて、だれのMIBがもテーブルでエントリーを数えるオブジェクトを定義するかをそうされます。 例はMIB-2 ifTable(ifNumberによる)、およびRMON historyControlTableを含んでいます。
Daniele, et. al. Standards Track [Page 8] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[8ページ]。
The subagent that implements such a counter object (like ifNumber) must go beyond AgentX to correctly implement it. This is an implementation issue (and most new MIB designs no longer include such objects).
そのようなカウンタオブジェクト(ifNumberのような)を実装する副代理店は、正しくそれを実装するためにAgentXを越えなければなりません。 これは導入問題(ほとんどの新しいMIBデザインはもうそのようなオブジェクトを含んでいない)です。
To implement row creation in such tables, at least one AgentX subagent must register at a point "higher" in the OID tree than an individual row (per AgentX's dispatching procedure). Again, this is an implementation issue.
そのようなテーブルで行作成を実装するために、少なくとも1つのAgentX副代理店がOIDでポイント「個々の行(AgentXの急ぎ手順あたりの)より高い」木に登録されなければなりません。 一方、これは導入問題です。
Scenarios in this category were thought to occur somewhat rarely in configurations where subagents are independently implemented by different vendors. The focus of a standard protocol, however, must be in just those areas where multi- vendor interoperability must be assured.
副代理店が異なったベンダーによって独自に実装されるところにこのカテゴリにおけるシナリオが構成でいくらかめったに起こらないと考えられました。 しかしながら、標準プロトコルの焦点がまさしくマルチベンダー相互運用性を保証しなければならないそれらの領域にあるに違いありません。
Note that it would be inefficient (due to AgentX registration overhead) to share a table among AgentX subagents if the table contains very dynamic instances, and each subagent registers fully qualified instances. ipRouteTable could be an example of such a table in some environments.
テーブルが非常にダイナミックなインスタンスを含むなら、AgentX副代理店の中に同席するのが効率が悪いことに(AgentX登録オーバーヘッドによる)注意してください。そうすれば、各副代理店は完全に適切なインスタンスを登録します。ipRouteTableはいくつかの環境におけるそのようなテーブルに関する例であるかもしれません。
4.3. Design Features of AgentX
4.3. AgentXに関する設計上の特徴
The primary features of the design described in this memo are:
このメモで説明されたデザインのプライマリ特徴は以下の通りです。
1) A general architectural division of labor between master agent
and subagent: The master agent is MIB ignorant and SNMP
omniscient, while the subagent is SNMP ignorant and MIB omniscient
(for the MIB variables it instantiates). That is, master agents,
exclusively, are concerned with SNMP protocol operations and the
translations to and from AgentX protocol operations needed to
carry them out; subagents are exclusively concerned with
management instrumentation; and neither should intrude on the
other's territory.
1) マスターエージェントと副代理店の間の一般的な建築分業: マスターエージェントは、MIB無知であって、SNMP全知です、副代理店は、SNMP無知であって、MIB全知ですが(それが例示するMIB変数のための)。 プロトコル操作が、それらを行う必要だったことをSNMPプロトコル操作とAgentXとAgentXからの翻訳にすなわち、マスターエージェントを排他的に心配させます。 副代理店は排他的に管理計装に関係があります。 そして、もう片方の領土にどちらも立ち入るべきではありません。
2) A standard protocol and "rules of engagement" to enable
interoperability between management instrumentation and extensible
agents.
2) 管理計装と広げることができるエージェントの間の可能にする標準プロトコルと「交戦規則」相互運用性。
3) Mechanisms for independently developed subagents to
integrate into the extensible agent on a particular managed node
in such a way that they need not be aware of any other existing
subagents.
3) 独自に開発された副代理店がそれらがいかなる他の既存の副代理店も意識している必要はないような方法で特定の管理されたノードの上の広げることができるエージェントと統合するメカニズム。
Daniele, et. al. Standards Track [Page 9] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[9ページ]。
4) A simple, deterministic registry and dispatching algorithm.
For a given extensible agent configuration, there is a single
subagent who is "authoritative" for any particular region of the
MIB (where "region" may extend from an entire MIB down to a single
object-instance).
4) 簡単で、決定論的な登録と急ぎアルゴリズム。 与えられた広げることができるエージェント構成のために、ただ一つのそうする副代理店がMIB(「領域」が全体のMIBからただ一つのオブジェクトインスタンスまで広がるかもしれないところ)のどんな特定の領域にも「正式」の状態であります。
5) Performance considerations. It is likely that the master
agent and all subagents will reside on the same host, and in such
cases AgentX is more a form of inter-process communication than a
traditional communications protocol.
5) パフォーマンス問題。 マスターエージェントとすべての副代理店が同じホストの上にありそうであって、そのような場合AgentXは伝統的な通信規約より相互プロセスコミュニケーションのフォームです。
Some of the design decisions made with this in mind include:
念頭でこれでされたデザイン決定のいくつかは:
- 32-bit alignment of data within PDUs
- PDUsの中のデータの32ビットの整列
- Native byte-order encoding by subagents
- 副代理店によるネイティブのバイトオーダーコード化
- Large AgentX PDU payload sizes.
- 大きいAgentX PDUペイロードサイズ。
4.4 Non-Goals
4.4 非目標
1) Subagent-to-subagent communication. This is out of scope,
due to the security ramifications and complexity involved.
1) 副代理店から副代理店へのコミュニケーション。 範囲の外にこれは分岐と複雑さが伴ったセキュリティのためにあります。
2) Subagent access (via the master agent) to MIB variables.
This is not addressed, since various other mechanisms are
available and it was not a fundamental requirement.
2) MIB変数への副代理店アクセス(マスターエージェントを通した)。 他の様々なメカニズムが利用可能であるので、これは扱われません、そして、それは基本的な要件ではありませんでした。
3) The ability to accommodate every conceivable extensible
agent configuration option. This was the most contentious aspect
in the development of this protocol. In essence, certain features
currently available in some commercial extensible agent products
are not included in AgentX. Although useful or even vital in some
implementation strategies, the rough consensus was that these
features were not appropriate for an Internet Standard, or not
typically required for independently developed subagents to
coexist. The set of supported extensible agent configurations is
described above, in Section 4.2.
3) 想像できるあらゆる広げることができるエージェント設定オプションに対応する能力。 これはこのプロトコルの開発で最も議論好きな局面でした。 本質では、現在いくつかの商業広げることができるエージェント製品の中に利用可能なある特徴はAgentXに含まれていません。 役に立つか、またはいくつかの実装戦略で重大でさえありますが、荒いコンセンサスはこれらの特徴がインターネットStandardには適切でなく、また独自に開発された副代理店が共存するのに通常必要でなかったということでした。 サポートしている広げることができるエージェント構成のセットはセクション4.2で上で説明されます。
Some possible future version of the AgentX protocol may provide coverage for one or more of these "non-goals" or for new goals that might be identified after greater deployment experience.
AgentXプロトコルの何らかの可能な将来のバージョンがこれらの「非目標」の1つ以上か、より大きい展開経験の後に特定されるかもしれない新しい目標に適用範囲を提供するかもしれません。
5. AgentX Encodings
5. AgentX Encodings
AgentX PDUs consist of a common header, followed by PDU-specific data of variable length. Unlike SNMP PDUs, AgentX PDUs are not encoded using the BER (as specified in ISO 8824 [1]), but are transmitted as
AgentX PDUsは可変長のPDU特有のデータがあとに続いた一般的なヘッダーから成ります。 SNMP PDUsと異なって、AgentX PDUsがBERを使用することでコード化されない、(ISO8824[1])で指定しますが、伝えられます。
Daniele, et. al. Standards Track [Page 10] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[10ページ]。
a contiguous byte stream. The data within this stream is organized to provide natural alignment with respect to the start of the PDU, permitting direct (integer) access by the processing entities.
隣接のバイト、流れてください。 このストリームの中のデータがPDUの始まりに関して自然な整列を提供するのが組織化されます、処理実体でダイレクト(整数)アクセスを可能にして。
The first four fields in the header are single-byte values. A bit (NETWORK_BYTE_ORDER) in the third field (h.flags) is used to indicate the byte ordering of all multi-byte integer values in the PDU, including those which follow in the header itself. This is described in more detail in Section 6.1, "AgentX PDU Header", below.
ヘッダーの最初の4つの分野が単一のバイト値です。 少し、(NETWORK_BYTE_ORDER)はPDUのすべてのマルチバイト整数値のバイト順を示すのに3番目の分野(h.旗)で使用されます、ヘッダー自体で続くものを含んでいて。 これはさらに詳細にセクション6.1、以下の「AgentX PDUヘッダー」で説明されます。
PDUs are depicted in this memo using the following convention (where byte 1 is the first transmitted byte):
PDUsはこのメモに以下のコンベンション(バイト1が最初の伝えられたバイトであるところ)を使用することで表現されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 1 | byte 2 | byte 3 | byte 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 5 | byte 6 | byte 7 | byte 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト1| バイト2| バイト3| バイト4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト5| バイト6| バイト7| バイト8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields marked "<reserved>" are reserved for future use and must be zero-filled.
「<は>を予約しました」であることが示される分野は、今後の使用のために予約されて、無いっぱいにしなければなりません。
5.1. Object Identifier
5.1. オブジェクト識別子
An object identifier is encoded as a 4-byte header, followed by a variable number of contiguous 4-byte fields representing sub- identifiers. This representation (termed Object Identifier) is as follows:
オブジェクト識別子はサブ識別子を表す可変数の隣接の4バイトの分野があとに続いた4バイトのヘッダーとしてコード化されます。 この表現(Object Identifierと呼ばれる)は以下の通りです:
Object Identifier
オブジェクト識別子
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Identifier header fields:
オブジェクトIdentifierヘッダーフィールド:
n_subid
n_subid
The number (0-128) of sub-identifiers in the object identifier.
An ordered list of "n_subid" 4-byte sub-identifiers follows the
4-byte header.
オブジェクト識別子のサブ識別子の数(0-128)。 「n_subid」4バイトのサブ識別子の規則正しいリストは4バイトのヘッダーに続きます。
Daniele, et. al. Standards Track [Page 11] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[11ページ]。
prefix
接頭語
An unsigned value used to reduce the length of object
identifier encodings. A non-zero value "x" is interpreted as
the first sub-identifier after "internet" (1.3.6.1), and
indicates an implicit prefix "internet.x" to the actual sub-
identifiers encoded in the Object Identifier. For example, a
prefix field value 2 indicates an implicit prefix "1.3.6.1.2".
A value of 0 in the prefix field indicates there is no prefix
to the sub-identifiers.
未署名の値は以前はオブジェクト識別子encodingsの長さをよく減少させていました。 非ゼロ値「x」が「インターネット」の後に最初のサブ識別子として解釈される、(1.3、.6、.1)、暗黙の接頭語"internet.x"をObject Identifierでコード化された実際のサブ識別子に示します。 例えば、接頭語分野価値2が暗黙の接頭語を示す、「1.3 .6 .1 0.2インチ」 接頭語分野の0の値は、サブ識別子への接頭語が全くないのを示します。
include
インクルード
Used only when the Object Identifier is the start of a
SearchRange, as described in section 5.2.
Object Identifierがセクション5.2で説明されるようにSearchRangeの始まりである場合にだけ、使用されています。
A null Object Identifier consists of the 4-byte header with all bytes set to 0.
ヌルObject Identifierは0に設定されたすべてのバイトで4バイトのヘッダーから成ります。
Examples:
例:
sysDescr.0 (1.3.6.1.2.1.1.1.0)
sysDescr.0(1.3.6.1.2.1.1.1.0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.2.3.4
1.2.3.4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 12] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[12ページ]。
5.2. SearchRange
5.2. SearchRange
A SearchRange consists of two Object Identifiers. In its communication with a subagent, the master agent uses a SearchRange to identify a requested variable binding, and, in GetNext and GetBulk operations, to set an upper bound on the names of managed object instances the subagent may send in reply.
SearchRangeは2Object Identifiersから成ります。 副代理店とのコミュニケーションでは、マスターエージェントは、そして、GetNextとGetBulk操作で要求された変項束縛を特定して、副代理店が回答で送るかもしれない管理オブジェクトインスタンスの名前に上限をけしかけるのにSearchRangeを使用します。
The first Object Identifier in a SearchRange (called the starting OID) indicates the beginning of the range. It is frequently (but not necessarily) the name of a requested variable binding.
SearchRange(始めのOIDと呼ばれる)における最初のObject Identifierは範囲の始まりを示します。 (必ずない)頻繁にそれは要求された変項束縛の名前です。
The "include" field in this OID's header is a boolean value (0 or 1) indicating whether or not the starting OID is included in the range.
このOIDのヘッダーの「包含」分野は始めのOIDが範囲に含まれているかどうかを示すブール値(0か1)です。
The second object identifier indicates the non-inclusive end of the range, and its "include" field is always 0.
第二目的語識別子は範囲の非含んでいる端を示します、そして、いつも「包含」分野は0です。
Example: To indicate a search range from 1.3.6.1.2.1.25.2 (inclusive) to 1.3.6.1.2.1.25.2.1 (exclusive), the SearchRange would be
例: 1.3から検索範囲を示す、.6、.1、.2、.1、.25、.2、(包括的)、1.3 .6 .1 .2 .1 .25 .2 .1 (排他的な)、SearchRangeはそうでしょう。
(start) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 2 | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(始めます) +++++++++++++++++++++++++++++++++| 3 | 2 | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(終わり)+++++++++++++++++++++++++++++++++| 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A SearchRangeList is a contiguous list of SearchRanges.
SearchRangeListはSearchRangesの隣接のリストです。
Daniele, et. al. Standards Track [Page 13] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[13ページ]。
5.3. Octet String
5.3. 八重奏ストリング
An octet string is represented by a contiguous series of bytes, beginning with a 4-byte integer whose value is the number of octets in the octet string, followed by the octets themselves. This representation is termed an Octet String. If the last octet does not end on a 4-byte offset from the start of the Octet String, padding bytes are appended to achieve alignment of following data. This padding must be added even if the Octet String is the last item in the PDU. Padding bytes must be zero filled.
八重奏ストリングは隣接のシリーズの何バイトも表されます、値が八重奏の八重奏自体があとに続いた八重奏ストリングの数である4バイトの整数で始まって。 この表現はOctet Stringと呼ばれます。 最後の八重奏がOctet Stringの始まりからの4バイトのオフセットのときに終わらないなら、次のデータの整列を達成するために詰め物バイトを追加します。 Octet StringがPDUで最後の項目であってもこの詰め物を加えなければなりません。 バイトを水増しするのは、いっぱいにされたゼロであるに違いありません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A null Octet String consists of a 4-byte length field set to 0.
ヌルOctet Stringは0に4バイトの長さの分野セットから成ります。
5.4. Value Representation
5.4. 値の表現
Variable bindings may be encoded within the variable-length portion of some PDUs. The representation of a variable binding (termed a VarBind) consists of a 2-byte type field, a name (Object Identifier), and the actual value data.
変項束縛はいくつかのPDUsの可変長の部分の中でコード化されるかもしれません。 変項束縛(VarBindと呼ばれる)の表現は2バイトのタイプ分野、名前(オブジェクトIdentifier)、および実価データから成ります。
VarBind
VarBind
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v. タイプしてください。| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.name) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(名前に対する) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 14] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[14ページ]。
(v.data) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(データに対する) +++++++++++++++++++++++++++++++++| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VarBind fields:
VarBind分野:
v.type
v. タイプしてください。
Indicates the variable binding's syntax, and must be one of
the following values:
変項束縛の構文を示して、以下の値の1つでなければなりません:
Integer (2),
Octet String (4),
Null (5),
Object Identifier (6),
IpAddress (64),
Counter32 (65),
Gauge32 (66),
TimeTicks (67),
Opaque (68),
Counter64 (70),
noSuchObject (128),
noSuchInstance (129),
endOfMibView (130)
整数(2)、八重奏ストリング(4)、ヌル(5)、オブジェクト識別子(6)、IpAddress(64)、Counter32(65)、Gauge32(66)(TimeTicks(67))は(68)について不透明にします、Counter64(70)、noSuchObject(128)、noSuchInstance(129)、endOfMibView(130)
v.name
v.名
The Object Identifier which names the variable.
変数を命名するObject Identifier。
v.data
v. データ
The actual value, encoded as follows:
以下の通りコード化された実価:
- Integer, Counter32, Gauge32, and TimeTicks are encoded as
4 contiguous bytes. If the NETWORK_BYTE_ORDER bit is set
in h.flags, the bytes are ordered most significant to least
significant, otherwise they are ordered least significant
to most significant.
- 整数、Counter32、Gauge32、およびTimeTicksは隣接の4バイトとしてコード化されます。 NETWORK_BYTE_ORDERビットがh.旗で設定されるなら、バイトは最も重要でなく最も重要な状態で命令されます。さもなければ、それらは最も重要に最も重要でなく注文されます。
- Counter64 is encoded as 8 contiguous bytes. If the
NETWORK_BYTE_ORDER bit is set in h.flags, the bytes are
ordered most significant to least significant, otherwise
they are ordered least significant to most significant.
- Counter64は隣接の8バイトとしてコード化されます。 NETWORK_BYTE_ORDERビットがh.旗で設定されるなら、バイトは最も重要でなく最も重要な状態で命令されます。さもなければ、それらは最も重要に最も重要でなく注文されます。
Daniele, et. al. Standards Track [Page 15] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[15ページ]。
- Object Identifiers are encoded as described in section
5.1, Object Identifier.
- Object Identifier、オブジェクトIdentifiersはセクション5.1で説明されるようにコード化されます。
- IpAddress, Opaque, and Octet String are all octet strings
and are encoded as described in section 5.3, Octet String.
- Octet String、IpAddress、Opaque、およびOctet Stringは八重奏ストリングであり、セクション5.3で説明されるようにコード化されます。
Value data always follows v.name whenever v.type is one
of the above types. These data bytes are present even if
they will not be used (as, for example, in certain types
of index allocation).
値のデータはいつも名前に対してv.タイプが上のタイプのひとりであるときはいつも、従います。 それらが使用されないでも(例えばあるタイプのインデックス配分のように)、これらのデータ・バイトは存在しています。
- Null, noSuchObject, noSuchInstance, and endOfMibView do not
contain any encoded value. Value data never follows
v.name in these cases.
- ヌル、noSuchObject、noSuchInstance、およびendOfMibViewは少しのコード化された値も含んでいません。 値のデータはこれらの場合における名前に対して決して従いません。
Note that the VarBind itself does not contain the value size.
That information is implied for the fixed-length types, and
explicitly contained in the encodings of variable-length types
(Object Identifier and Octet String).
VarBind自身が値のサイズを含まないことに注意してください。 その情報は、固定長タイプのために含意されて、可変長のタイプ(オブジェクトIdentifierとOctet String)のencodingsに明らかに含まれています。
A VarBindList is a contiguous list of VarBinds. Within a VarBindList, a particular VarBind is identified by an index value. The first VarBind in a VarBindList has index value 1, the second has index value 2, and so on.
VarBindListはVarBindsの隣接のリストです。 VarBindListの中では、特定のVarBindはインデックス値によって特定されます。 VarBindListにおける最初のVarBindには、インデックス値1があって、2番目にインデックス値2などがあります。
6. Protocol Definitions
6. プロトコル定義
6.1. AgentX PDU Header
6.1. AgentX PDUヘッダー
The AgentX PDU header is a fixed-format, 20-octet structure:
AgentX PDUヘッダーは固定形式の、そして、20八重奏の構造です:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version | h.type | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. バージョン| h. タイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An AgentX PDU header contains the following fields:
AgentX PDUヘッダーは以下の分野を含んでいます:
h.version
h. バージョン
The version of the AgentX protocol (1 for this memo).
AgentXプロトコル(このメモのための1)のバージョン。
Daniele, et. al. Standards Track [Page 16] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[16ページ]。
h.type
h. タイプしてください。
The PDU type; one of the following values:
PDUはタイプします。 以下の値の1つ:
agentx-Open-PDU (1),
agentx-Close-PDU (2),
agentx-Register-PDU (3),
agentx-Unregister-PDU (4),
agentx-Get-PDU (5),
agentx-GetNext-PDU (6),
agentx-GetBulk-PDU (7),
agentx-TestSet-PDU (8),
agentx-CommitSet-PDU (9),
agentx-UndoSet-PDU (10),
agentx-CleanupSet-PDU (11),
agentx-Notify-PDU (12),
agentx-Ping-PDU (13),
agentx-IndexAllocate-PDU (14),
agentx-IndexDeallocate-PDU (15),
agentx-AddAgentCaps-PDU (16),
agentx-RemoveAgentCaps-PDU (17),
agentx-Response-PDU (18)
agentxの開いているPDU(1)、agentxの近いPDU(2)、agentxレジスタPDU(3)、agentx-Unregister-PDU(4)、agentxがPDUを手に入れている(5)、agentx-GetNext-PDU(6)、agentx-GetBulk-PDU(7)、agentx-TestSet-PDU(8)、agentx-CommitSet-PDU(9)、agentx-UndoSet-PDU(10)、agentx-CleanupSet-PDU(11)、agentxがPDUに通知している(12)、agentxピングPDU(13)、agentx-IndexAllocate-PDU(14)、agentx-IndexDeallocate-PDU(15)、agentx-AddAgentCaps-PDU(16)、agentx-RemoveAgentCaps-PDU(17)、agentx応答PDU(18)
h.flags
h. 旗
A bitmask, with bit 0 the least significant bit. The bit
definitions are as follows:
ビット0があるビットマスク、最下位ビット。 噛み付いている定義は以下の通りです:
Bit Definition
--- ----------
0 INSTANCE_REGISTRATION
1 NEW_INDEX
2 ANY_INDEX
3 NON_DEFAULT_CONTEXT
4 NETWORK_BYTE_ORDER
5-7 (reserved)
噛み付いている定義--- ---------- 0 どんな_インデックス3非_のデフォルト_文脈4ネットワーク_バイト_も5-7に注文するインスタンス_登録1の新しい_インデックス2(予約される)です。
The NETWORK_BYTE_ORDER bit applies to all multi-byte integer
values in the entire AgentX packet, including the remaining
header fields. If set, then network byte order (most
significant byte first; "big endian") is used. If not set,
then least significant byte first ("little endian") is used.
NETWORK_BYTE_ORDERビットは残っているヘッダーフィールドを含む全体のAgentXパケットのすべてのマルチバイト整数値に適用されます。 設定されるならバイトオーダーをネットワークでつないでください、(最も重要なバイト、1番目; 「ビッグエンディアン」) 使用されます。 設定されないなら、最も重要でないバイトは最初に、使用されています(「リトルエンディアン」)。
The NETWORK_BYTE_ORDER bit applies to all AgentX PDUs.
NETWORK_BYTE_ORDERビットはすべてのAgentX PDUsに適用されます。
The NON_DEFAULT_CONTEXT bit is used only in the AgentX PDUs
described in section 6.1.1.
NON_DEFAULT_CONTEXTビットはセクション6.1.1で説明されたAgentX PDUsだけで使用されます。
Daniele, et. al. Standards Track [Page 17] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[17ページ]。
The NEW_INDEX and ANY_INDEX bits are used only within the
agentx-IndexAllocate-, and -IndexDeallocate-PDUs.
NEW_INDEXとどんな_INDEXビットもagentx-IndexAllocate、および-IndexDeallocate-PDUsだけの中で使用されます。
The INSTANCE_REGISTRATION bit is used only within the agentx-
Register-PDU.
INSTANCE_REGISTRATIONビットはagentxレジスタ-PDUだけの中で使用されます。
h.sessionID
h. sessionID
The session ID uniquely identifies a session over which AgentX
PDUs are exchanged between a subagent and the master agent.
The session ID has no significance and no defined value in the
agentx-Open-PDU sent by a subagent to open a session with the
master agent; in this case, the master agent will assign a
unique sessionID that it will pass back in the corresponding
agentx-Response-PDU. From that point on, that same sessionID
will appear in every AgentX PDU exchanged over that session
between the master and the subagent. A subagent may establish
multiple AgentX sessions by sending multiple agentx-Open-PDUs
to the master agent.
セッションIDは唯一、AgentX PDUsが副代理店とマスターエージェントの間で交換されるセッションを特定します。 セッションIDは副代理店によって送られた、マスターエージェントと共に開会したagentxの開いているPDUに意味がなくて定義された値を全く持っていません。 この場合、マスターエージェントはそれが対応するagentx応答PDUで戻すユニークなsessionIDを割り当てるでしょう。 そのポイントから、その同じsessionIDはマスターと副代理店とのそのセッションの間に交換されたあらゆるAgentX PDUに現れるでしょう。 副代理店は、複数のagentxの開いているPDUsをマスターエージェントに送ることによって、複数のAgentXセッションを確立するかもしれません。
In master agents that support multiple transport protocols, the
sessionID should be globally unique rather than unique just to
a particular transport.
複数の輸送がプロトコルであるとサポートするマスターエージェントでは、まさしく特定の輸送にユニークであるというよりむしろsessionIDはグローバルにユニークであるべきです。
h.transactionID
h. transactionID
The transaction ID uniquely identifies, for a given session,
the single SNMP management request (and single SNMP PDU) with
which an AgentX PDU is associated. If a single SNMP management
request results in multiple AgentX PDUs being sent by the
master agent with the same sessionID, each of these AgentX PDUs
must contain the same transaction ID; conversely, AgentX PDUs
sent during a particular session, that result from distinct
SNMP management requests, must have distinct transaction IDs
within the limits of the 32-bit field).
トランザクションIDは与えられたセッションのために、唯一、AgentX PDUが関連しているただ一つのSNMP管理要求(SNMP PDUを選抜する)を特定します。 ただ一つのSNMP経営者側が同じsessionIDのマスターエージェントによって送られる複数のAgentX PDUsで結果を要求するなら、それぞれのこれらのAgentX PDUsは同じトランザクションIDを含まなければなりません。 逆に、AgentX PDUsは特定のセッションの間、発信して、異なったSNMP管理要求、必須からの結果は32ビットの分野の限界の中に異なったトランザクションIDを持っています)
Note that the transaction ID is not the same as the SNMP PDU's
request-id (as described in section 4.1 of RFC 1905 [4]), nor
can it be, since a master agent might receive SNMP requests
with the same request-ids from different managers.
トランザクションIDがSNMP PDUの要求イドと同じでないことに注意してください。(説明されるように、または、マスターエージェントが同じ要求イドで異なったマネージャからSNMP要求を受け取るかもしれないので、それはセクション4.1のRFC1905[4])にあるはずがありません。
The transaction ID has no significance and no defined value in
AgentX administrative PDUs, i.e., AgentX PDUs that are not
associated with an SNMP management request.
トランザクションIDはAgentXの管理PDUs(すなわち、SNMP管理要求に関連づけられないAgentX PDUs)に意味がなくて定義された値を全く持っていません。
Daniele, et. al. Standards Track [Page 18] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[18ページ]。
h.packetID
h. packetID
A packet ID generated by the sender for all AgentX PDUs except
the agentx-Response-PDU. In an agentx-Response-PDU, the packet
ID must be the same as that in the received AgentX PDU to which
it is a response. A master agent might use this field to
associate subagent response PDUs with their corresponding
request PDUs. A subagent might use this field to correlate
responses to multiple (batched) registrations.
IDがagentx応答PDU以外のすべてのAgentX PDUsのために送付者で生成したパケット。 agentx応答PDUでは、パケットIDはそれが応答である容認されたAgentX PDUのそれと同じであるに違いありません。 マスターエージェントは、彼らの対応する要求PDUsに副代理店応答PDUsを関連づけるのにこの分野を使用するかもしれません。 副代理店は、複数の(batchedしました)登録証明書への応答を関連させるのにこの分野を使用するかもしれません。
h.payload_length
h. ペイロード_長さ
The size in octets of the PDU contents, excluding the 20-byte
header. As a result of the encoding schemes and PDU layouts,
this value will always be either 0, or a multiple of 4.
20バイトのヘッダーを除いたPDUコンテンツの八重奏におけるサイズ。 コード化体系とPDUレイアウトの結果、この値は、いつも4の0か倍数のどちらかになるでしょう。
6.1.1. Context
6.1.1. 文脈
In the SNMPv1 or v2c frameworks, the community string may be used as an index into a local repository of configuration information that may include community profiles or more complex context information. Future versions of the SNMP will likely formalize this notion of "context".
SNMPv1かv2cフレームワークでは、共同体ストリングはインデックスとして共同体プロフィールを含むかもしれない設定情報か、より複雑な文脈情報の地方の倉庫に使用されるかもしれません。 SNMPの将来のバージョンはおそらく「文脈」のこの概念を正式にするでしょう。
AgentX provides a mechanism for transmitting a context specification within relevant PDUs, but does not place any constraints on the content of that specification.
AgentXは関連PDUsの中で文脈仕様を伝えるのにメカニズムを提供しますが、その仕様の内容に少しの規制も置きません。
An optional context field may be present in the agentx-Register-, UnRegister-, AddAgentCaps-, RemoveAgentCaps-, Get-, GetNext-, GetBulk-, IndexAllocate-, IndexDeallocate-, Notify-, TestSet-, and Ping- PDUs.
任意の文脈分野がagentx-レジスタに存在しているかもしれない、-、UnRegister、AddAgentCaps、RemoveAgentCaps、Get、GetNext、GetBulk、IndexAllocate、IndexDeallocate、Notify、TestSet、およびPing- PDUs。
If the NON_DEFAULT_CONTEXT bit in the AgentX header field h.flags is clear, then there is no context field in the PDU, and the operation refers to the default context.
AgentXヘッダーフィールドh.旗によるNON_DEFAULT_CONTEXTビットが明確であるなら、文脈分野が全くPDUにありません、そして、操作はデフォルト文脈を示します。
If the NON_DEFAULT_CONTEXT bit is set, then a context field immediately follows the AgentX header, and the operation refers to that specific context. The context is represented as an Octet String. There are no constraints on its length or contents.
NON_DEFAULT_CONTEXTビットが設定されるなら、文脈分野はすぐにAgentXヘッダーに続きます、そして、操作はその特定の文脈を示します。 文脈はOctet Stringとして表されます。 規制が全くその長さかコンテンツにありません。
Thus, all of these AgentX PDUs (that is, those listed immediately above) refer to, or "indicate" a context, which is either the default context, or a non-default context explicitly named in the PDU.
したがって、これらのAgentX PDUs(すなわち、すぐに上に記載されたもの)のすべてが、文脈を示すか、または「示します」。(それは、PDUで明らかに指定されたデフォルト文脈か非デフォルト文脈のどちらかです)。
Daniele, et. al. Standards Track [Page 19] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[19ページ]。
6.2. AgentX PDUs
6.2. AgentX PDUs
6.2.1. The agentx-Open-PDU
6.2.1. agentxの開いているPDU
An agentx-Open-PDU is generated by a subagent to request establishment of an AgentX session with the master agent.
agentxの開いているPDUは副代理店によって生成されて、マスターエージェントとのAgentXセッションの設立を要求します。
(AgentX header)
(AgentXヘッダー)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (1) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. バージョン(1)| h. (1)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.timeout | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.timeout| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.イド) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「副-識別子」#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「副-識別子」#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.descr) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.descr) +++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Open-PDU contains the following fields:
agentxの開いているPDUは以下の分野を含んでいます:
Daniele, et. al. Standards Track [Page 20] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[20ページ]。
o.timeout
o.timeout
The length of time, in seconds, that a master agent should
allow to elapse after dispatching a message to a subagent
before it regards the subagent as not responding. This is a
subagent-wide default value that may be overridden by values
associated with specific registered MIB regions. The default
value of 0 indicates that no subagent-wide value is requested.
秒のマスターエージェントがそれの前に副代理店に送信した後に経過するのを許すべきである時間の長さは、副代理店が応じていないとみなします。 これは特定の登録されたMIB領域に関連している値によってくつがえされるかもしれない副代理店全体のデフォルト値です。 0のデフォルト値は、どんな副代理店全体の値も要求されていないのを示します。
o.id
o.id
An Object Identifier that identifies the subagent. Subagents
that do not support such an notion may send a null Object
Identifier.
副代理店を特定するObject Identifier。 そのような概念をサポートしない副代理店はヌルObject Identifierを送るかもしれません。
o.descr
o.descr
An Octet String containing a DisplayString describing the
subagent.
副代理店について説明するDisplayStringを含むOctet String。
6.2.2. The agentx-Close-PDU
6.2.2. agentxの近いPDU
An agentx-Close-PDU issued by either a subagent or the master agent terminates an AgentX session.
副代理店かマスターエージェントのどちらかによって発行されたagentxの近いPDUはAgentXセッションを終えます。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (2) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (2)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c.reason | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c. 理由| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Close-PDU contains the following field:
agentxの近いPDUは以下の分野を含んでいます:
Daniele, et. al. Standards Track [Page 21] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[21ページ]。
c.reason
c. 理由
An enumerated value that gives the reason that the master agent
or subagent closed the AgentX session. This field may take one
of the following values:
マスターエージェントか副代理店がAgentXセッションを終えた理由をあげる列挙された値。 この分野は以下の値の1つを取るかもしれません:
reasonOther(1)
None of the following reasons
以下のいずれも推論しないreasonOther(1)
reasonParseError(2)
Too many AgentX parse errors from peer
reasonParseError(2)、多く過ぎるAgentXは同輩から誤りを分析します。
reasonProtocolError(3)
Too many AgentX protocol errors from peer
reasonProtocolError(3)、多く過ぎるAgentXは同輩から誤りについて議定書の中で述べます。
reasonTimeouts(4)
Too many timeouts waiting for peer
reasonTimeouts(4)、同輩を待つあまりに多くのタイムアウト
reasonShutdown(5)
Sending entity is shutting down
reasonShutdown(5)送付実体は停止しています。
reasonByManager(6)
Due to Set operation; this reason code can be used only
by the master agent, in response to an SNMP management
request.
Set操作へのreasonByManager(6)Due。 単にマスターエージェントはSNMP管理要求に対応してこの理由コードを使用できます。
6.2.3. The agentx-Register-PDU
6.2.3. agentxレジスタPDU
An agentx-Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within one or more contexts) that it wishes to support.
agentxレジスタPDUは副代理店でそれが支持したがっているMIBの可変命名木(1つ以上の文脈の中の)の各領域に発生します。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (3) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (3)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 22] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[22ページ]。
(r.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.文脈) (任意)の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r.timeout | r.priority | r.range_subid | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r. タイムアウト| r. 優先権| r. 範囲_subid| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.region)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.領域) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional upper-bound sub-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 任意の上限サブ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Register-PDU contains the following fields:
agentxレジスタPDUは以下の分野を含んでいます:
r.context
r. 文脈
An optional non-default context.
任意の非デフォルト文脈。
r.timeout
r. タイムアウト
The length of time, in seconds, that a master agent should
allow to elapse after dispatching a message to a subagent
before it regards the subagent as not responding. r.timeout
applies only to messages that concern MIB objects within
r.region. It overrides both the subagent-wide value (if any)
indicated when the AgentX session with the master agent was
established, and the master agent's default timeout. The
default value for r.timeout is 0 (no override).
秒のマスターエージェントがそれの前に副代理店に送信した後に経過するのを許すべきである時間の長さは、副代理店が応じていないとみなします。r.タイムアウトは関心MIBがr.領域の中で反対するというメッセージだけに適用されます。 それはマスターエージェントとのAgentXセッションが確立されたとき副代理店全体の値(もしあれば)が示した両方、およびマスターエージェントのデフォルトタイムアウトをくつがえします。 r.タイムアウトのためのデフォルト値は0(オーバーライドがない)です。
Daniele, et. al. Standards Track [Page 23] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[23ページ]。
r.priority
r. 優先権
A value between 1 and 255, used to achieve a desired
configuration when different subagents register identical or
overlapping regions. Subagents with no particular knowledge of
priority should register with the default value of 255 (lowest
priority).
1と255の間の異なった副代理店が同じ状態で登録されるとき、必要な構成を達成するのに使用されるか、または領域を重ね合わせる値。 優先権に関する特定の知識のない副代理店は255(最も低い優先度)のデフォルト値とともに記名するべきです。
In the master agent's dispatching algorithm, smaller values of
r.priority take precedence over larger values, as described in
section 7.1.5.1.
マスターエージェントの急ぎアルゴリズムで、r.優先権の、より小さい値はセクション7.1.5で.1に説明されるように、より大きい値の上で優先します。
r.region
r. 領域
An Object Identifier that, in conjunction with r.range_subid,
indicates a region of the MIB that a subagent wishes to
support. It may be a fully-qualified instance name, a partial
instance name, a MIB table, an entire MIB, or ranges of any of
these.
r.範囲_subidに関連して副代理店が支持したがっているMIBの領域を示すObject Identifier。 それは完全に適切な例の名であるかもしれません、部分的な例の名、MIBテーブル、全体のMIB、または範囲のこれらのいずれも。
The choice of what to register is implementation-specific; this
memo does not specify permissible values. Standard practice
however is for a subagent to register at the highest level of
the naming tree that makes sense. Registration of fully-
qualified instances is typically done only when a subagent can
perform management operations only on particular rows of a
conceptual table.
登録するべきことの選択は実現特有です。 このメモは許容値を指定しません。 しかしながら、標準的技法は理解できる命名木の最高水準で登録する副代理店のためのものです。 副代理店が概念的なテーブルの特定の列だけに管理操作を実行できるときだけ、通常完全に適切な例の登録をします。
If r.region is in fact a fully qualified instance name, the
INSTANCE_REGISTRATION bit in h.flags must be set, otherwise it
must be cleared. The master agent may save this information to
optimize subsequent operational dispatching.
事実上、r.領域が完全に適切な例の名であるなら、h.旗によるINSTANCE_REGISTRATIONビットを設定しなければなりません。さもなければ、それは晴れなければなりません。 マスターエージェントは、その後の操作上の急ぎを最適化するためにこの情報を保存するかもしれません。
r.range_subid
r. 範囲_subid
Permits specifying a range in place of one of r.region's sub-
identifiers. If this value is 0, no range is specified.
Otherwise the "r.range_subid"-th sub-identifier in r.region is
a range lower bound, and the range upper bound sub-identifier
(r.upper_bound) immediately follows r.region.
r.領域のサブ識別子の1つに代わって範囲を指定する許可証。 この値が0であるなら、範囲は全く指定されません。 そうでなければ、「r.範囲_subid」、-、中のサブ識別子r.領域は範囲下界であり、範囲上限サブ識別子(r.の上側の_は固まった)はすぐに、r.領域に第続きます。
This permits registering a conceptual row with a single PDU.
For example, the following PDU would register row 7 of the RFC
1573 ifTable (1.3.6.1.2.1.2.2.1.1-22.7):
これは、概念的な列を独身のPDUに示すことを許可します。 例えば、以下のPDUはRFC1573ifTable(1.3.6.1.2.1.2.2.1.1-22.7)の列7を示すでしょう:
Daniele, et. al. Standards Track [Page 24] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[24ページ]。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (3) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (3)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.timeout | r.priority | 5 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r. タイムアウト| r. 優先権| 5 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.領域) +++++++++++++++++++++++++++++++++| 6 | 2 | 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.4. The agentx-Unregister-PDU
6.2.4. agentx-Unregister-PDU
The agentx-Unregister-PDU is sent by a subagent to remove a previously registered MIB region from the master agent's OID space.
副代理店でagentx-Unregister-PDUを送って、マスターエージェントのOIDスペースから以前に登録されたMIB領域を取り除きます。
Daniele, et. al. Standards Track [Page 25] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[25ページ]。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (4) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (4)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <reserved> | u.priority | u.range_subid | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <は>を予約しました。| u. 優先権| u. 範囲_subid| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.領域) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional upper-bound sub-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 任意の上限サブ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Unregister-PDU contains the following fields:
agentx-Unregister-PDUは以下の分野を含んでいます:
Daniele, et. al. Standards Track [Page 26] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[26ページ]。
u.context
u. 文脈
An optional non-default context.
任意の非デフォルト文脈。
u.priority
u. 優先権
The priority at which this region was originally registered.
この領域が元々登録された優先権。
u.region
u. 領域
Indicates a previously-registered region of the MIB that a
subagent no longer wishes to support.
副代理店がもう支持したがっていないMIBの以前に登録された領域を示します。
6.2.5. The agentx-Get-PDU
6.2.5. agentxはPDUを手に入れます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (5) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (5)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
(g.sr)
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1を始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 27] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[27ページ]。
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(終わり1) +++++++++++++++++++++++++++++++++| 0 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (始めn) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(終わりn) +++++++++++++++++++++++++++++++++| 0 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Get-PDU contains the following fields:
agentxにPDUを手に入れてください、以下の分野を含んでいます:
g.context
g. 文脈
An optional non-default context.
任意の非デフォルト文脈。
g.sr
g. sr
A SearchRangeList containing the requested variables for this
subagent.
この副代理店のための要求された変数を含むSearchRangeList。
Daniele, et. al. Standards Track [Page 28] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[28ページ]。
6.2.6. The agentx-GetNext-PDU
6.2.6. agentx-GetNext-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (6) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (6)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
(g.sr)
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1を始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(終わり1) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 29] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[29ページ]。
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(nを始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(終わりn) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
6.2.7. The agentx-GetBulk-PDU
6.2.7. agentx-GetBulk-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (7) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (7)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 30] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[30ページ]。
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g.non_repeaters | g.max_repetitions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g. 非_のリピータ| g. 最大_反復| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr) as in agentx-GetNext-PDU above
...
(g.sr) 上のagentx-GetNext-PDUのように…
6.2.8. The agentx-TestSet-PDU
6.2.8. agentx-TestSet-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (8) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (8)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.vb)
(t.vb)
Daniele, et. al. Standards Track [Page 31] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[31ページ]。
(VarBind 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(VarBind1) +++++++++++++++++++++++++++++++++| v. タイプしてください。| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
(VarBind n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(VarBind n)+++++++++++++++++++++++++++++++++| v. タイプしてください。| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-TestSet-PDU contains the following fields:
agentx-TestSet-PDUは以下の分野を含んでいます:
t.context
t. 文脈
An optional non-default context.
任意の非デフォルト文脈。
Daniele, et. al. Standards Track [Page 32] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[32ページ]。
t.vb
t. vb
A VarBindList containing the requested VarBinds for this
subagent.
この副代理店のための要求されたVarBindsを含むVarBindList。
6.2.9. The agentx-CommitSet, -UndoSet, -CleanupSet PDUs
6.2.9. agentx-CommitSet、-UndoSet、-CleanupSet PDUs
These PDUs consist of the AgentX header only.
これらのPDUsはAgentXヘッダーだけから成ります。
The agentx-CommitSet-, -UndoSet-, and -Cleanup-PDUs are used in processing an SNMP SetRequest operation.
agentx-CommitSet、-UndoSet、-クリーンアップ-PDUsはSNMP SetRequest操作を処理する際に使用されます。
6.2.10. The agentx-Notify-PDU
6.2.10. agentxはPDUに通知しています。
An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification.
agentxはPDUに通知します。マスターエージェントが通知を転送することを引き起こす副代理店で、送ります。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (12) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (12)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.vb)
...
(n.vb)…
An agentx-Notify-PDU contains the following fields:
agentxにPDUに通知してください、以下の分野を含んでいます:
Daniele, et. al. Standards Track [Page 33] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[33ページ]。
n.context
n. 文脈
An optional non-default context.
任意の非デフォルト文脈。
n.vb
n. vb
A VarBindList whose contents define the actual PDU to be sent.
This memo places the following restrictions on its contents:
コンテンツが送るために実際のPDUを定義するVarBindList。 このメモはコンテンツに関して以下の制限を課します:
- If the subagent supplies sysUpTime.0, it must be
present as the first varbind.
- 副代理店がsysUpTime.0を供給するなら、最初のvarbindとして存在していなければなりません。
- snmpTrapOID.0 must be present, as the second
varbind if sysUpTime.0 was supplied, as the first if it
was not.
- それが存在していなかったなら、sysUpTime.0であるなら1番目として2番目のvarbindを供給したとき、snmpTrapOID.0は存在していなければなりません。
6.2.11 The agentx-Ping-PDU
6.2.11 agentxピングPDU
The agentx-Ping-PDU is sent by a subagent to the master agent to monitor the master agent's ability to receive and send AgentX PDUs over their AgentX session.
副代理店でagentxピングPDUをマスターエージェントに送って、彼らのAgentXセッションの間にAgentX PDUsを受けて、送るマスターエージェントの能力をモニターします。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (13) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (13)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(p.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(p.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Ping-PDU may contain the following field:
agentxピングPDUは以下の分野を含むかもしれません:
Daniele, et. al. Standards Track [Page 34] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[34ページ]。
p.context
p. 文脈
An optional non-default context.
任意の非デフォルト文脈。
Using p.context a subagent can retrieve the sysUpTime value for a specific context, if required.
必要なら、p.文脈を使用して、副代理店は特定の文脈のためにsysUpTime値を検索できます。
6.2.12. The agentx-IndexAllocate-PDU
6.2.12. agentx-IndexAllocate-PDU
An agentx-IndexAllocate-PDU is sent by a subagent to request allocation of a value for specific index objects. Refer to section 7.1.3 (Using the agentx-IndexAllocate-PDU) for suggested usage.
副代理店でagentx-IndexAllocate-PDUを送って、特定のインデックス物のために価値の配分を要求します。 提案された用法についてセクション7.1.3(agentx-IndexAllocate-PDUを使用する)を参照してください。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (14) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (14)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.vb)
...
(i.vb)…
An agentx-IndexAllocate-PDU contains the following fields:
agentx-IndexAllocate-PDUは以下の分野を含んでいます:
i.context
i. 文脈
An optional non-default context.
任意の非デフォルト文脈。
Daniele, et. al. Standards Track [Page 35] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[35ページ]。
i.vb
i. vb
A VarBindList containing the index names and values requested
for allocation.
配分のために要求されたインデックス名と値を含むVarBindList。
6.2.13. The agentx-IndexDeallocate-PDU
6.2.13. agentx-IndexDeallocate-PDU
An agentx-IndexDeallocate-PDU is sent by a subagent to release previously allocated index values.
副代理店でagentx-IndexDeallocate-PDUを送って、以前に割り当てられたインデックス値をリリースします。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (15) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. バージョン(1)| h. (15)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.vb)
...
(i.vb)…
An agentx-IndexDeallocate-PDU contains the following fields:
agentx-IndexDeallocate-PDUは以下の分野を含んでいます:
i.context
i. 文脈
An optional non-default context.
任意の非デフォルト文脈。
i.vb
i. vb
A VarBindList containing the index names and values to be
released.
リリースされるべきインデックス名と値を含むVarBindList。
Daniele, et. al. Standards Track [Page 36] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[36ページ]。
6.2.14. The agentx-AddAgentCaps-PDU
6.2.14. agentx-AddAgentCaps-PDU
An agentx-AddAgentCaps-PDU is generated by a subagent to inform the master agent of its agent capabilities.
agentx-AddAgentCaps-PDUは副代理店で発生して、エージェント能力についてマスターエージェントに知らせます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (16) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (16)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Optional Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.文脈) (任意)の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| 任意の詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.イド) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.descr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.descr) +++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 37] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[37ページ]。
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Optional Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| 任意の詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-AddAgentCaps-PDU contains the following fields:
agentx-AddAgentCaps-PDUは以下の分野を含んでいます:
a.context
a. 文脈
An optional non-default context.
任意の非デフォルト文脈。
a.id
a. イド
An Object Identifier containing the value of an invocation of
the AGENT-CAPABILITIES macro, which the master agent exports as
a value of sysORID for the indicated context. (Recall that the
value of an invocation of an AGENT-CAPABILITIES macro is an
object identifier that describes a precise level of support
with respect to implemented MIB modules. A more complete
discussion of the AGENT-CAPABILITIES macro and related sysORID
values can be found in section 6 of RFC 1904 [10].)
マスターエージェントが示された文脈のためにsysORIDの値として輸出するエージェント-CAPABILITIESマクロの実施の値を含むObject Identifier。 (エージェント-CAPABILITIESマクロの実施の値が実行されたMIBモジュールに関して正確なサポート水準について説明する物の識別子であると思い出してください。 RFC1904[10]のセクション6でエージェント-CAPABILITIESマクロと関連するsysORID値の、より完全な議論を見つけることができます。)
a.descr
a. descr
An Octet String containing a DisplayString to be used as the
value of sysORDescr corresponding to the sysORID value above.
sysORID値へのsysORDescr対応の上の値として使用されるべきDisplayStringを含むOctet String。
6.2.15. The agentx-RemoveAgentCaps-PDU
6.2.15. agentx-RemoveAgentCaps-PDU
An agentx-RemoveAgentCaps-PDU is generated by a subagent to request that the master agent stop exporting a particular value of sysORID. This value must have previously been advertised by the subagent in an agentx-AddAgentCaps-PDU.
agentx-RemoveAgentCaps-PDUは副代理店で発生して、マスターエージェントが、sysORIDの特定の値を輸出するのを止めるよう要求します。 副代理店は以前に、agentx-AddAgentCaps-PDUにこの値の広告を出したに違いありません。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (17) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (17)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 38] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[38ページ]。
(a.context) (OPTIONAL) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Optional Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.文脈) (任意)の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| 任意の詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.イド) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-RemoveAgentCaps-PDU contains the following fields:
agentx-RemoveAgentCaps-PDUは以下の分野を含んでいます:
a.context
a. 文脈
An optional non-default context.
任意の非デフォルト文脈。
a.id
a. イド
An ObjectIdentifier containing the value of sysORID that should
no longer be exported.
もう輸出されるべきでないsysORIDの値を含むObjectIdentifier。
6.2.16. The agentx-Response-PDU
6.2.16. agentx応答PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (18) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. バージョン(1)| h. (18)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 39] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[39ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.sysUpTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.error | res.index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.sysUpTime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.error| res.index| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
An agentx-Response-PDU contains the following fields:
agentx応答PDUは以下の分野を含んでいます:
h.sessionID
h. sessionID
If this is a response to a agentx-Open-PDU, then it contains
the new and unique sessionID (as assigned by the master agent)
for this session.
これがagentxの開いているPDUへの応答であるなら、それはこのセッションのために、新しくてユニークなsessionID(マスターエージェントによって割り当てられるように)を含んでいます。
Otherwise it must be identical to the h.sessionID value in the
PDU to which this PDU is a response.
さもなければ、それはこのPDUが応答であるPDUのh.sessionID価値と同じであるに違いありません。
h.transactionID
h. transactionID
Must be identical to the h.transactionID value in the PDU to
which this PDU is a response.
このPDUが応答であるPDUのh.transactionID価値と同じにしなければならなくなってください。
In an agentx response PDU from the master agent to the
subagent, the value of h.transactionID has no significance and
can be ignored by the subagent.
マスターエージェントから副代理店までの応答PDU、agentxのh.transactionIDの値は、意味を全く持たないで、副代理店で無視できます。
h.packetID
h. packetID
Must be identical to the h.packetID value in the PDU to which
this PDU is a response.
このPDUが応答であるPDUのh.packetID価値と同じにしなければならなくなってください。
res.sysUpTime
res.sysUpTime
This field contains the current value of sysUpTime for the
indicated context. It is relevant only in agentx response PDUs
sent from the master agent to a subagent in response to the
following agentx PDUs:
この分野は示された文脈のためのsysUpTimeの現行価値を含んでいます。 それは以下のagentx PDUsに対応してマスターエージェントから副代理店に送られたagentx応答PDUsだけで関連しています:
agentx-Open-PDU (1),
agentx-Close-PDU (2),
agentx-Register-PDU (3),
agentx-Unregister-PDU (4),
agentx-Ping-PDU (13),
agentx-IndexAllocate-PDU (14),
agentx-IndexDeallocate-PDU (15),
agentx-AddAgentCaps-PDU (16),
agentx-RemoveAgentCaps-PDU (17)
agentxの開いているPDU(1)、agentxの近いPDU(2)、agentxレジスタPDU(3)、agentx-Unregister-PDU(4)、agentxピングPDU(13)、agentx-IndexAllocate-PDU(14)、agentx-IndexDeallocate-PDU(15)、agentx-AddAgentCaps-PDU(16)、agentx-RemoveAgentCaps-PDU(17)
Daniele, et. al. Standards Track [Page 40] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[40ページ]。
In an agentx response PDU from the subagent to the master
agent, the value of res.sysUpTime has no significance and is
ignored by the master agent.
agentx応答では、副代理店からマスターエージェントまでのPDU、res.sysUpTimeの値は、意味を全く持たないで、マスターエージェントによって無視されます。
res.error
res.error
Indicates error status (including `noError'). Values are
limited to those defined for errors in the SNMPv2 SMI (RFC 1905
[4]), and the following AgentX-specific values:
エラー状況('noError'を含んでいる)を示します。 値がSNMPv2 SMIの誤りによって定義されたものに制限される、(RFC1905[4])、および以下のAgentX特有の値:
openFailed (256),
notOpen (257),
indexWrongType (258),
indexAlreadyAllocated (259),
indexNoneAvailable (260),
indexNotAllocated (261),
unsupportedContext (262),
duplicateRegistration (263),
unknownRegistration (264),
unknownAgentCaps (265)
(256)、notOpen(257)、indexWrongType(258)、indexAlreadyAllocated(259)、indexNoneAvailable(260)、indexNotAllocated(261)、unsupportedContext(262)、duplicateRegistration(263)、unknownRegistration(264)、unknownAgentCapsをopenFailedしました。(265)
res.index
res.index
In error cases, this is the index of the failed variable
binding within a received request PDU. (Note: As explained in
section 5.4, Value Representation, the index values of variable
bindings within a variable binding list are 1-based.)
誤り事件では、これは容認された要求PDUの中の失敗した変項束縛のインデックスです。 (注意: セクション5.4、Value Representationで説明されるように、変項束縛リストの中の変項束縛のインデックス値は1ベースです。)
A VarBindList may follow these latter two fields, depending on which AgentX PDU is being responded to. These data are specified in the subsequent elements of procedure.
どのAgentX PDUが応じているかによって、VarBindListはこれらの後者の2つの野原に続くかもしれません。 これらのデータは手順のその後の要素で指定されます。
7. Elements of Procedure
7. 手順のElements
This section describes the actions of protocol entities (master agents and subagents) implementing the AgentX protocol. Note, however, that it is not intended to constrain the internal architecture of any conformant implementation.
このセクションは、AgentXプロトコルを実行しながら、プロトコル実体(マスターエージェントと副代理店)の動作について説明します。 しかしながら、どんなconformant実現の内部の構造も抑制することを意図しないことに注意してください。
Specific error conditions and associated actions are described in various places. Other error conditions not specifically mentioned fall into one of two categories, "parse" errors and "protocol" errors.
特定のエラー条件と関連動作は様々な場所で説明されます。 明確に言及されなかった他のエラー条件は、2つのカテゴリの1つになって、誤りを「分析し」て、誤りについて「議定書の中で述べます」。
A parse error occurs when a receiving entity cannot decode the PDU. For instance, a VarBind contains an unknown type, or a PDU contains a malformed Object Identifier.
Aは分析されます。受信実体がPDUを解読できない誤りは発生します。 例えば、VarBindが未知のタイプを含んでいるか、またはPDUは奇形のObject Identifierを含んでいます。
Daniele, et. al. Standards Track [Page 41] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[41ページ]。
A protocol error occurs when a receiving entity can parse a PDU, but the resulting data is unspecified. For instance, an agentx- Response-PDU is successfully parsed, but contains an unknown res.error value.
受信実体がPDUを分析できるとき、プロトコル誤りは発生しますが、結果として起こるデータは不特定です。 例えば、agentx応答-PDUは首尾よく分析されますが、未知のres.error値を含んでいます。
An implementation may choose either to ignore such messages, or to close the session on which they are received, using the appropriate reason code as defined in the agentx-Close-PDU.
実現は、そのようなメッセージを無視するか、またはそれらが受け取られているセッションを終えるのを選ぶかもしれません、agentxの近いPDUで定義されるように適切な理由コードを使用して。
The actions of AgentX protocol entities can be broadly categorized under two headings, each of which is described separately:
2つの見出しの下でAgentXプロトコル実体の動作を露骨に分類できます:それのそれぞれが別々に見出しのために説明されます。
(1) processing AgentX administrative messages (e.g., connection
requests from a subagent to a master agent); and
(1) AgentXの管理メッセージ(例えば、副代理店からマスターエージェントまでの接続要求)を処理します。 そして
(2) processing SNMP messages (the coordinated actions of a
master agent and one or more subagents in processing, for
example, a received SNMP GetRequest-PDU).
(2) 処理SNMPメッセージ(マスターエージェントの連携動作と処理、例えば、容認されたSNMP GetRequest-PDUの1つ以上の副代理店)。
7.1. Processing AgentX Administrative Messages
7.1. AgentXの管理メッセージを処理します。
This subsection describes the actions of AgentX protocol entities in processing AgentX administrative messages. Such messages include those involved in establishing and terminating an AgentX session between a subagent and a master agent, those by which a subagent requests allocation of instance index values, and those by which a subagent communicates to a master agent which MIB regions it supports.
この小区分はAgentXの管理メッセージを処理することにおける、AgentXプロトコル実体の動作について説明します。 そのようなメッセージは副代理店とマスターエージェント(副代理店が例のインデックス値、および副代理店が、それがどのMIB領域を支持するかをマスターエージェントに伝えるそれらの配分を要求するそれら)とのAgentXセッションを確立して、終える際に関係者を含んでいます。
7.1.1. Processing the agentx-Open-PDU
7.1.1. agentxの開いているPDUを処理します。
When the master agent receives an agentx-Open-PDU, it processes it as follows:
マスターエージェントがagentxの開いているPDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the indicated context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeは示された文脈のためにsysUpTime.0の値に用意ができています。
2) If the master agent is unable to open an AgentX session for
any reason, it may refuse the session establishment request,
sending in reply the agentx-Response-PDU, with res.error field set
to `openFailed'.
2) マスターエージェントがどんな理由でもAgentXセッションを開くことができないなら、設立が要求するセッションを拒否するかもしれません、回答におけるres.errorとagentx応答PDU分野セットを'openFailed'に送って。
3) Otherwise: The master agent assigns a sessionID to the new
session and puts the value in the h.sessionID field of the
agentx-Response-PDU. This value must be unique among all existing
open sessions.
3) そうでなければ: マスターエージェントは、新しいセッションまでsessionIDを割り当てて、agentx応答PDUのh.sessionID分野に値を置きます。 この値はすべての既存の公開審議の中でユニークであるに違いありません。
Daniele, et. al. Standards Track [Page 42] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[42ページ]。
4) The master agent retains session-specific information
from the PDU for this subagent:
4) マスターエージェントはこの副代理店のためのPDUからのセッション特殊情報を保有します:
- The NETWORK_BYTE_ORDER value in h.flags is retained.
All subsequent AgentX protocol operations initiated by the
master agent for this session must use this byte ordering and
set this bit accordingly.
- h.旗によるNETWORK_BYTE_ORDER価値は保有されます。 このセッションのためにマスターエージェントによって開始されたすべてのその後のAgentXプロトコル操作が、このバイト順を使用して、それに従って、このビットを設定しなければなりません。
The subagent typically sets this bit to correspond to its
native byte ordering, and typically does not vary byte ordering
for an initiated session. The master agent must be able to
decode each PDU according to the h.flag NETWORK_BYTE_ORDER bit
in the PDU, but does not need to toggle its retained value for
the session if the subagent varies its byte ordering.
副代理店は、このビットにネイティブのバイト順に相当するように通常設定して、開始しているセッションのためにバイト順を通常変えません。 マスターエージェントは、h.旗のNETWORK_BYTE_ORDERビットに従ってPDUで各PDUを解読できなければなりませんが、副代理店がバイト順を変えるなら、セッションのために保有された値を切り換える必要はありません。
- The o.timeout value is used in calculating response
timeout conditions for this subagent.
- o.タイムアウト価値はこの副代理店に計算の応答タイムアウト状態で使用されます。
- The o.id and o.descr fields are used for informational
purposes. (Such purposes are implementation-specific for now,
and may be used in a possible future standard AgentX MIB.)
- o.イドとo.descr分野は情報の目的に使用されます。 (そのような目的は、当分実現特有であり、可能な将来の標準のAgentX MIBで使用されるかもしれません。)
5) The agentx-Response-PDU is sent with the res.error field
set to `noError'.
5) res.error分野セットでagentx応答PDUを'noError'に送ります。
At this point, an AgentX session is considered established between the master agent and the subagent. An AgentX session is a distinct channel for the exchange of AgentX protocol messages between a master agent and one subagent, qualified by the session-specific attributes listed in 4) above. AgentX session establishment is initiated by the subagent. An AgentX session can be terminated by either the master agent or the subagent.
ここに、AgentXセッションはマスターエージェントと副代理店の間で確立していると考えられます。 AgentXセッションは4で)記載されたセッション特有の属性によって上に資格があったマスターエージェントと1つの副代理店の間のAgentXプロトコルメッセージの交換のための異なったチャンネルです。 AgentXセッション設立は副代理店によって開始されます。 マスターエージェントか副代理店のどちらかはAgentXセッションを終えることができます。
7.1.2. Processing the agentx-IndexAllocate-PDU
7.1.2. agentx-IndexAllocate-PDUを処理します。
When the master agent receives an agentx-IndexAllocate-PDU, it processes it as follows:
マスターエージェントがagentx-IndexAllocate-PDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
2) If h.sessionID does not correspond to a currently established
session with this subagent, the agentx-Response-PDU is sent in
reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
Daniele, et. al. Standards Track [Page 43] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[43ページ]。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested allocation fails. Otherwise: The value of res.sysUpTime
is set to the value of sysUpTime.0 for the indicated context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された配分は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
4) Each VarBind in the VarBindList is processed until either all
are successful, or one fails. If any VarBind fails, the agentx-
Response-PDU is sent in reply containing the original VarBindList,
with res.index set to indicate the failed VarBind, and with
res.error set as described subsequently. All other VarBinds are
ignored; no index values are allocated.
4) すべてがうまくいっているか、または1つが失敗するまで、VarBindListの各VarBindは処理されます。 どれかVarBindが失敗するなら、agentx応答-PDUは失敗したVarBindを示すres.index set、および次に説明されるように用意ができているres.errorとオリジナルのVarBindListを含む送られた回答です。 他のすべてのVarBindsが無視されます。 インデックス値を全く割り当てません。
VarBinds are processed as follows:
VarBindsは以下の通り処理されます:
- v.name is the name of the index for which a value is to be
allocated.
- v. 名前は割り当てられる値がことであるインデックスの名前です。
- v.type is the syntax of the index object.
- v. タイプはインデックス物の構文です。
- v.data indicates the specific index value requested.
If the NEW_INDEX or the ANY_INDEX bit is set, the actual value
in v.data is ignored and an appropriate index value is
generated.
- v. データは値が要求した特定のインデックスを示します。 または、NEW_INDEXである、どんな_INDEXビットも設定されて、v.データの実価は無視されて、適切なインデックス値は発生します。
a) If there are no currently allocated index values for v.name
in the indicated context, and v.type does not correspond to a
valid index type value, the VarBind fails and res.error is set
to `indexWrongType'.
a) 示された文脈にはv.名のための現在割り当てられたインデックス値が全くなくて、またv.タイプが有効なインデックスタイプ価値に文通していないなら、VarBindは失敗します、そして、res.errorは'indexWrongType'に用意ができています。
b) If there are currently allocated index values for v.name
in the indicated context, but the syntax of those values does
not match v.type, the VarBind fails and res.error is set to
`indexWrongType'.
b) 示された文脈にはv.名のための現在割り当てられたインデックス値がありますが、それらの値の構文がタイプに対して合っていないなら、VarBindは失敗します、そして、res.errorは'indexWrongType'に用意ができています。
c) Otherwise, if both the NEW_INDEX and ANY_INDEX bits are
clear, allocation of a specific index value is being requested.
If the requested index is already allocated for v.name in the
indicated context, the VarBind fails and res.error is set to
`indexAlreadyAllocated'.
c) さもなければ、NEW_INDEXとどんな_INDEXビットの両方も明確であるなら、特定のインデックス価値の配分は要求されています。 示された文脈のv.名のために既に要求されたインデックスを割り当てるなら、VarBindは失敗します、そして、res.errorは'indexAlreadyAllocated'に用意ができています。
d) Otherwise, if the NEW_INDEX bit is set, the master agent
should generate the next available index value for v.name in
the indicated context, with the constraint that this value must
not have been allocated (even if subsequently released) to any
subagent since the last re-initialization of the master agent.
If no such value can be generated, the VarBind fails and
res.error is set to `indexNoneAvailable'.
d) さもなければ、NEW_INDEXビットが設定されるなら、マスターエージェントは示された文脈のv.名のために次の利用可能なインデックス値を発生させるべきです、マスターエージェントの最後の再初期化以来この値をどんな副代理店にも割り当てていてはいけないという(次にリリースされても)規制で。 何かそのような値が発生できないなら、VarBindは失敗します、そして、res.errorは'indexNoneAvailable'に用意ができています。
Daniele, et. al. Standards Track [Page 44] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[44ページ]。
e) Otherwise, if the ANY_INDEX bit is set, the master agent
should generate an index value for v.name in the indicated
context, with the constraint that this value is not currently
allocated to any subagent. If no such value can be generated,
then the VarBind fails and res.error is set to
`indexNoneAvailable'.
e) そうでなければ、どんな_INDEXビットも設定されて、マスターエージェントは示された文脈のv.名のためにインデックス値を発生させるべきです、この値が現在どんな副代理店にも割り当てられないという規制で。 何かそのような値が発生できないなら、VarBindは失敗します、そして、res.errorは'indexNoneAvailable'に用意ができています。
5) If all VarBinds are processed successfully, the
agentx-Response-PDU is sent in reply with res.error set to
`noError'. A VarBindList is included that is identical to the one
sent in the agentx-IndexAllocate-PDU, except that VarBinds
requesting a NEW_INDEX or ANY_INDEX value are generated with an
appropriate value.
5) 首尾よくすべてのVarBindsを処理するなら、'noError'に用意ができているres.errorとの回答でagentx応答PDUを送ります。 含まれていたものと同じVarBindListはagentx-IndexAllocate-PDUを送りました、NEW_INDEXかどんな_INDEX価値も要求するVarBindsが適切な値で発生するのを除いて。
7.1.3. Using the agentx-IndexAllocate-PDU
7.1.3. agentx-IndexAllocate-PDUを使用します。
Index allocation is a service provided by an AgentX master agent. It provides generic support for sharing MIB conceptual tables among subagents who are assumed to have no knowledge of each other.
インデックス配分はAgentXマスターエージェントによって提供されたサービスです。 それは、互いに関する知識を全く持たないように概念的な副代理店の中のそうするMIBテーブルを共有するために想定されていた状態で一般的なサポートを提供します。
Each subagent sharing a table should first request allocation of index values, then use those index values to qualify MIB regions in its subsequent registrations.
同席する各副代理店は、最初に、インデックス値の配分を要求して、次に、その後の登録証明書におけるMIB領域に資格を与えるのにそれらのインデックス値を使用するべきです。
The master agent maintains a database of index objects (OIDs), and, for each index, the values that have been allocated for it. It is unaware of what MIB variables (if any) the index objects represent.
そして、マスターエージェントは各インデックス(それのために割り当てられた値)のためにインデックス物(OIDs)に関するデータベースを維持します。 インデックス物がどんなMIB変数(もしあれば)を表すかにそれは気づきません。
By convention, subagents use the MIB variable listed in the INDEX clause as the index object for which values must be allocated. For tables indexed by multiple variables, values may be allocated for each index (although this is frequently unnecessary; see example 2 below). The subagent may request allocation of
コンベンションで、副代理店は値を割り当てなければならないインデックス物としてINDEX節に記載されたMIB変数を使用します。 複数の変数によって索引をつけられたテーブルに関しては各インデックスのために値を割り当てるかもしれない、(これは頻繁に不要です; 以下の例2を見てください、) 副代理店は配分を要求するかもしれません。
- a specific index value - an index value that is not currently
allocated - an index value that has never been allocated
- 特定のインデックス値--現在割り当てられないインデックス値--一度も割り当てられたことがないインデックス値
The last two alternatives reflect the uniqueness and constancy requirements present in many MIB specifications for arbitrary integer indexes (e.g., ifIndex in the IF MIB (RFC 1573 [11]), snmpFddiSMTIndex in the FDDI MIB (RFC 1285 [12]), or sysApplInstallPkgIndex in the System Application MIB [13]). The need for subagents to share tables using such indexes is the main motivation for index allocation in AgentX.
最後の2つの選択肢が任意の整数インデックスのための多くのMIB仕様の現在のユニークさと不変性要件を反映する、(例えば、IF MIBのifIndex、(RFC1573[11])、FDDI MIBのsnmpFddiSMTIndex、(RFC1285[12])、またはSystem Application MIB[13])のsysApplInstallPkgIndex。 副代理店がそのようなインデックスを使用することでテーブルを共有する必要性はAgentXでのインデックス配分に関する主な動機です。
Daniele, et. al. Standards Track [Page 45] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[45ページ]。
Example 1:
例1:
A subagent implements an interface, and wishes to register a
single row of the RFC 1573 ifTable. It requests an allocation for
the index object "ifIndex", for a value that has never been
allocated (since ifIndex values must be unique). The master agent
returns the value "7".
副代理店はインタフェース、およびRFC1573ifTableの一つの列を示すという願望を実行します。 それはインデックス物の"ifIndex"のために配分を要求します、一度も割り当てられたことがない値のために(ifIndex値がユニークであるに違いないので)。 マスターエージェントは「7インチ」を値に返します。
The subagent now attempts to register row 7 of ifTable, by
specifying a MIB region in the agentx-Register-PDU of
1.3.6.1.2.1.2.2.1.[1-22].7. If the registration succeeds, no
further processing is required. The master agent will dispatch to
this subagent correctly.
副代理店は、現在、1.3.6.1.2.1.2.2.1.[1-22]のagentxレジスタPDU.7におけるMIB領域を指定することによってifTableの列7を示すのを試みます。 登録が成功するなら、どんなより遠い処理も必要ではありません。 マスターエージェントは正しくこの副代理店に急ぐでしょう。
But the registration may fail. Index allocation and MIB region
registration are not coupled in the master agent. Some other
subagent may have already registered ifTable row 7 without first
having requested allocation of the index. The current state of
index allocations is not considered when processing registration
requests, and the current registry is not considered when
processing index allocation requests. If subagents follow the
model of "first request allocation of an index, then register the
corresponding region", then a successful index allocation request
gives a subagent a good hint (but no guarantee) of what it should
be able to register.
しかし、登録は失敗するかもしれません。 インデックス配分とMIB領域登録はマスターエージェントで結合されません。 最初にインデックスの配分を要求していなくて、ある他の副代理店は既にifTable列7を示したかもしれません。 登録要求を処理する場合、インデックス配分の現状は考えられません、そして、インデックス配分要求を処理するとき、現在の登録は考えられません。 副代理店が「最初に、インデックスの配分を要求してください、そして、次に、対応部分を登録してください」のモデルに従うなら、うまくいっているインデックス配分要求はそれが何であるべきであるかに関する良いヒント(しかし、保証がない)を副代理店に登録できる状態で与えます。
If the registration failed, the subagent should request allocation
of a new index i, and attempt to register ifTable.[1-22].i, until
successful.
登録が失敗するなら、副代理店は、新しいインデックスiの配分を要求して、ifTable.[1-22].iを登録するのを試みるでしょうに、うまくいくまで。
Example 2:
例2:
This same subagent wishes to register ipNetToMediaTable rows
corresponding to its interface (ifIndex i). Due to structure of
this table, no further index allocation need be done. The
subagent can register the MIB region ipNetToMediaTable.[1-4].i, It
is claiming responsibility for all rows of the table whose value
of ipNetToMediaIfIndex is i.
この同じ副代理店はインタフェース(ifIndex i)に対応するipNetToMediaTable列を示したがっています。 このテーブルの構造のため、さらなるインデックス配分を全くする必要はありません。 副代理店はMIB領域ipNetToMediaTable.[1-4].iを登録できて、ItはipNetToMediaIfIndexの値がiであるテーブルのすべての列に犯行声明を出しています。
Example 3:
例3:
A network device consists of a set of processors, each of which
accepts network connections for a unique set of IP addresses.
ネットワーク装置は1セットのプロセッサから成ります。それはそれぞれユニークなIPアドレスのためのネットワーク接続を受け入れます。
Further, each processor contains a subagent that implements
tcpConnTable. In order to represent tcpConnTable for the entire
managed device, the subagents need to share tcpConnTable.
さらに、各プロセッサはtcpConnTableを実行する副代理店を含んでいます。 全体の管理された装置のためにtcpConnTableを表すために、副代理店は、tcpConnTableを共有する必要があります。
Daniele, et. al. Standards Track [Page 46] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[46ページ]。
In this case, no index allocation need be done at all. Each
subagent can register a MIB region of tcpConnTable.[1-5].a.b.c.d,
where a.b.c.d represents an unique IP address of the individual
processor.
この場合、全くインデックス配分をする必要はありません。 各副代理店はtcpConnTable.[1-5].a.b.c.dのMIB領域を登録できます。(そこでは、a.b.c.dは個々のプロセッサの固有のIPアドレスを表します)。
Each subagent is claiming responsibility for the region of
tcpConnTable where the value of tcpConnLocalAddress is a.b.c.d.
各副代理店はtcpConnLocalAddressの値がa.b.c.dであるtcpConnTableの領域に犯行声明を出しています。
7.1.4 Processing the agentx-IndexDeallocate-PDU
7.1.4 agentx-IndexDeallocate-PDUを処理すること。
When the master agent receives an agentx-IndexDeallocate-PDU, it processes it as follows:
マスターエージェントがagentx-IndexDeallocate-PDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested deallocation fails. Otherwise: The value of
res.sysUpTime is set to the value of sysUpTime.0 for the indicated
context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された反配分は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
4) Each VarBind in the VarBindList is processed until either all
are successful, or one fails. If any VarBind fails, the agentx-
Response-PDU is sent in reply, containing the original
VarBindList, with res.index set to indicate the failed VarBind,
and with res.error set as described subsequently. All other
VarBinds are ignored; no index values are released.
4) すべてがうまくいっているか、または1つが失敗するまで、VarBindListの各VarBindは処理されます。 どれかVarBindが失敗するなら、回答でagentx応答-PDUを送ります、失敗したVarBindを示すres.index set、および次に説明されるように用意ができているres.errorとオリジナルのVarBindListを含んでいて。 他のすべてのVarBindsが無視されます。 インデックス値は全くリリースされません。
VarBinds are processed as follows:
VarBindsは以下の通り処理されます:
- v.name is the name of the index for which a value is to be
released
- v. 名前はリリースされる値がことであるインデックスの名前です。
- v.type is the syntax of the index object
- v. タイプはインデックス物の構文です。
- v.data indicates the specific index value to be released.
The NEW_INDEX and ANY_INDEX bits are ignored.
- v. データは、リリースされるために特定のインデックス値を示します。 NEW_INDEXとどんな_INDEXビットも無視されます。
a) If the index value for the named index is not currently
allocated to this subagent, the VarBind fails and res.error is
set to `indexNotAllocated'.
a) 命名されたインデックスのためのインデックス値が現在この副代理店に割り当てられないなら、VarBindは失敗します、そして、res.errorは'indexNotAllocated'に用意ができています。
Daniele, et. al. Standards Track [Page 47] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[47ページ]。
5) If all VarBinds are processed successfully, res.error is
set to `noError' and the agentx-Response-PDU is sent. A
VarBindList is included which is identical to the one sent in the
agentx-IndexDeallocate-PDU.
5) すべてのVarBindsが首尾よく処理されるなら、res.errorは'noError'に用意ができています、そして、agentx応答PDUを送ります。 VarBindListは含まれています(agentx-IndexDeallocate-PDUで送られたものと同じです)。
All released index values are now available, and may be used in
response to subsequent allocation requests for ANY_INDEX values
for the particular index.
すべてのリリースされたインデックス値が、現在、利用可能であり、特定のインデックスにどんな_INDEX値を求めるその後の配分要求に対応して使用されるかもしれません。
7.1.5. Processing the agentx-Register-PDU
7.1.5. agentxレジスタPDUを処理します。
When the master agent receives an agentx-Register-PDU, it processes it as follows:
マスターエージェントがagentxレジスタPDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested registration fails. Otherwise: The value of
res.sysUpTime is set to the value of sysUpTime.0 for the indicated
context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された登録は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
Note: Non-default contexts might be added on the fly by
the master agent, or the master agent might require such
non-default contexts to be pre-configured. The choice is
implementation-specific.
以下に注意してください。 非デフォルト文脈がマスターエージェントによって急いで言い足されるかもしれませんか、またはマスターエージェントは、そのような非デフォルト文脈があらかじめ設定されるのを必要とするかもしれません。 選択は実現特有です。
4) Characterize the request.
4) 要求を特徴付けてください。
If r.region (or any of its set of Object Identifiers, if r.range
is non-zero) is exactly the same as any currently registered value
of r.region (or any of its set of Object Identifiers), this
registration is termed a duplicate region.
r. 領域(Object Identifiersのセットのどれかであり、r.であるなら、範囲は非ゼロである)がまさにr.領域(または、Object Identifiersのセットのどれか)のどんな現在登録された値とも同じであるなら、この登録は写し領域と呼ばれます。
If r.region (or any of its set of Object Identifiers, if r.range
is non-zero) is a subtree of, or contains, any currently
registered value of r.region (or any of its set of Object
Identifiers), this registration is termed an overlapping region.
r. 領域(Object Identifiersのセットのどれかであり、r.であるなら、範囲は非ゼロである)が下位木である、含有、r.領域(または、Object Identifiersのセットのどれか)のどんな現在登録された値、この登録は重なっている領域と呼ばれます。
If the NON_DEFAULT_CONTEXT bit is set, this region is to be
logically registered within the context indicated by r.context.
NON_DEFAULT_CONTEXTビットが設定されるなら、この領域はr.文脈によって示された文脈の中に論理的に登録されることです。
Daniele, et. al. Standards Track [Page 48] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[48ページ]。
Otherwise this region is to be logically registered within the
default context.
さもなければ、この領域はデフォルト文脈の中に論理的に登録されることです。
A registration that would result in a duplicate region with the
same priority and within the same context as that of a current
registration is termed a duplicate registration.
同じ優先権とそれと同じ文脈の中で写し領域をもたらす現金書留の登録は写し登録と呼ばれます。
5) Otherwise, if this is a duplicate registration, the
agentx-Response-PDU is returned with res.error set to
`duplicateRegistration', and the requested registration fails.
5) さもなければ、これが写し登録であるなら、'duplicateRegistration'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された登録は失敗します。
6) Otherwise, the agentx-Response-PDU is returned with res.error
set to `noError'.
6) さもなければ、'noError'に用意ができているres.errorでagentx応答PDUを返します。
The master agent adds this region to its registered OID space for
the indicated context, to be considered during the dispatching
phase for subsequently received SNMP protocol messages.
マスターエージェントは、次に受信されたSNMPプロトコルメッセージのために急ぎ段階の間、考えられるために示された文脈のための登録されたOIDスペースにこの領域を加えます。
Note: The following algorithm describes maintaining a set of OID
ranges derived from "splitting" registered regions. The algorithm
for operational dispatching is also stated in terms of these OID
ranges.
以下に注意してください。 以下のアルゴリズムは、「分かれること」の登録された領域から得られた1セットのOID範囲を維持すると説明します。 また、操作上の急ぎのためのアルゴリズムはこれらのOID範囲で述べられています。
These OID ranges are a useful explanatory device, but are not
required for a correct implementation.
これらのOID範囲は、役に立つ説明している装置ですが、正しい実現に必要ではありません。
- If r.region (R1) is a subtree of a currently registered
region (R2), split R2 into 3 new regions (R2a, R2b, and R2c)
such that R2b is an exact duplicate of R1. Now remove R2 and
add R1, R2a, R2b, and R2c to the master agent's
lexicographically ordered set of ranges (the registered OID
space). Note: Though newly-added ranges R1 and R2b are
identical in terms of the MIB objects they contain, they are
registered by different subagents, possibly at different
priorities.
- r.領域(R1)が現在登録された領域(R2)の下位木であるなら、R2bがR1の正確な写しであるようにR2を3つの新しい領域(R2a、R2b、およびR2c)に分割してください。 今度は、R2を取り外してください、そして、マスターエージェントの辞書編集の順序集合の範囲(登録されたOIDスペース)にR1、R2a、R2b、およびR2cを加えてください。 以下に注意してください。 新たに加えられた範囲のR1とR2bはそれらが含むMIB物が同じですが、それらは異なった副代理店によって登録されます、ことによると異なったプライオリティで。
For instance, if subagent S2 registered "ip" (R2 is
1.3.6.1.2.1.4) and subagent S1 subsequently registered
"ipNetToMediaTable" (R1 is 1.3.6.1.2.1.4.22), the resulting set
of registered regions would be:
R1はそうです。例えば、S2が副代理店であるなら"ip"を登録した、(R2、S1が次に登録した1.3の.6の.1の.2の.1の.4と)副代理店が"ipNetToMediaTable"である、(1.3 .6 .1 .2 .1 .4 .22)、結果として起こるセットの登録された領域は以下の通りでしょう。
1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2)
1.3.6.1.2.1.4、しかし、1.3に.6を含んでいなくて、含んでいない1.3.6.1.2.1.4.23(S1による)1.3.6の.1.2.1.4.23上だけへの含んでいない1.3の.1.2.1.4.22上にもかかわらず、含んでいない.6.1.2.1.4.22(S2による)1.3.6の.1.2.1.4.22 1.3.6.1.2.1.4.23(S2による)1.3.6上だけへ上昇する、.1、.2、.1、.5(S2による)
Daniele, et. al. Standards Track [Page 49] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[49ページ]。
- If r.region (R1) overlaps one or more currently registered
regions, then for each overlapped region (R2) split R1 into 3
new ranges (R1a, R1b, R1c) such that R1b is an exact
duplicate of R2. Add R1b and R2 into the lexicographically
ordered set of regions. Apply (5) above iteratively to R1a and
R1c (since they may overlap, or be subtrees of, other regions).
- r.領域(R1)が1つ以上の現在登録された領域を重ね合わせるならそれぞれの重ね合わせられた領域のために、(R2)がR1を3つの新しい範囲(R1a、R1b、R1c)に分割したので、R1bはR2の正確な写しです。 辞書編集の順序集合の領域にR1bとR2を加えてください。 繰り返しの上でR1aとR1cに(5)を適用してください、(それらが重なるか、または下位木であるかもしれない、他の領域)
For instance, given the currently registered regions in the
example above, if subagent S3 now registers mib-2 (R1 is
1.3.6.1.2.1) the resulting set of regions would be:
R1はそうです。例えば、上記の例の現在登録された領域を考えて、S3が副代理店であるなら現在mib-2を登録する、(1.3 .6 .1 .2 .1) 結果として起こるセットの領域は以下の通りでしょう。
1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3)
1.3.6.1.2.1 含んでいない1だけへのしか含んでいない1.3の.1.2.1.4.22上にもかかわらず、含んでいない.6.1.2.1.4.22(S3による)1.3.6の.1.2.1.4.22 1.3.6.1.2.1.4.23(S2による)1.3.6上でないことへの含んでいない1.3の.6.1.2.1.4(S3による)1.3.6.1.2.1.4上にもかかわらず、含んでいない1.3.6.1.2.1.4.22(S2による)1.3.6.1.2.1.4上だけへ上昇してください; 3.6.1.2.1.4.23 含んでいない1.3だけへのしか含んでいない1.3の.1.2.1.4.23.6.1.2.1.5(S2による)1.3.6上にもかかわらず、含んでいない1.3の.6.1.2.1.5(S3による)1.3.6.1.2.1.5上でないことへの(S1による)1.3.6.1.2.1.4.22上にもかかわらず、含んでいない1.3.6.1.2.1.4.23(S3による)1.3.6の.1.2.1.4.23上、.6、.1、.2、.2(S3による)
Note that at registration time a region may be split into multiple OID ranges due to pre-existing registrations, or as a result of any subsequent registration. This region splitting is transparent to subagents. Hence the master agent must always be able to associate any OID range with the information contained in its original agentx- Register-PDU.
登録時に領域が登録証明書を先在させるか、またはどんなその後の登録の結果、複数のOID範囲に分けられるかもしれないことに注意してください。 この領域の分かれるのは副代理店に透明です。 したがって、マスターエージェントはいつもオリジナルのagentxレジスタ-PDUに含まれている情報にどんなOID範囲も関連づけることができなければなりません。
7.1.5.1. Handling Duplicate OID Ranges
7.1.5.1. 取り扱い写しOIDは及びます。
As a result of this registration algorithm there are likely to be duplicate OID ranges (regions of identical MIB objects registered to different subagents) in the master agent's registered OID space. Whenever the master agent's dispatching algorithm (see 7.2.1, Dispatching AgentX PDUs) results in a duplicate OID range, the master agent selects one to use, termed the 'authoritative region', as follows:
この登録アルゴリズムの結果、写しOID範囲(異なった副代理店に登録された同じMIB物の領域)がマスターエージェントの登録されたOIDスペースにおそらくあるでしょう。 マスターエージェントがアルゴリズムを派遣する、(見る、7.2、.1、Dispatching AgentX PDUs) 写しOID範囲の結果、マスターエージェントは以下の'正式の領域'と呼ばれた使用への1つを選択します:
1) Choose the one whose original agentx-Register-PDU
r.region contained the most subids, i.e., the most specific
r.region. Note: The presence or absence of a range subid has
no bearing on how "specific" one object identifier is compared
to another.
1) 元のagentxレジスタPDU r.領域が含んだ中ですなわち、最も多くのsubids、r.領域最も特定であるものを選んでください。 以下に注意してください。 範囲subidの存在か不在には、1つの「特定」の物の識別子がどう別のものと比較されるかの堪えることがありません。
2) If still ambiguous, there were duplicate regions. Choose the
one whose original agentx-Register-PDU specified the smaller
value of r.priority.
2) まだあいまいであるなら、写し領域がありました。 オリジナルのagentxレジスタPDUがr.優先権の、より小さい値を指定したものを選んでください。
Daniele, et. al. Standards Track [Page 50] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[50ページ]。
7.1.6. Processing the agentx-Unregister-PDU
7.1.6. agentx-Unregister-PDUを処理します。
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested unregistration fails. Otherwise: The value of
res.sysUpTime is set to the value of sysUpTime.0 for the indicated
context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された非登録は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
4) If u.region, u.priority, and the indicated context do not match
an existing registration made during this session, the agentx-
Response-PDU is returned with res.error set to
`unknownRegistration'.
4) u.領域、u.優先権、および示された文脈が今会期中にされた既存の登録に合っていないなら、'unknownRegistration'に用意ができているres.errorでagentx応答-PDUを返します。
5) Otherwise, the agentx-Response-PDU is sent in reply with res.error
set to `noError', and the previous registration is removed:
5) さもなければ、'noError'に用意ができているres.errorとの回答でagentx応答PDUを送ります、そして、前の登録を取り除きます:
- The master agent removes u.region from its registered OID space
within the indicated context. If the original region had been
split, all such related regions are removed.
- マスターエージェントは示された文脈の中の登録されたOIDスペースからu.領域を取り除きます。 元の領域が分裂であったなら、そのようなすべての関連する領域を取り除きます。
For instance, given the example registry above, if subagent S2
unregisters "ip", the resulting registry would be:
例えば、上の例の登録を考えて、副代理店S2 unregisters"ip"であるなら、結果として起こる登録は以下の通りでしょう。
1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3)
上げる..しかし..含む..上..含む..上..しかし..含む..上..含む..上..しかし..含む..上..しかし..含む(S3による)
7.1.7. Processing the agentx-AddAgentCaps-PDU
7.1.7. agentx-AddAgentCaps-PDUを処理します。
When the master agent receives an agentx-AddAgentCaps-PDU, it processes it as follows:
マスターエージェントがagentx-AddAgentCaps-PDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
Daniele, et. al. Standards Track [Page 51] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[51ページ]。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested operation fails. Otherwise: The value of res.sysUpTime
is set to the value of sysUpTime.0 for the indicated context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された操作は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
4) Otherwise, the master agent adds the subagent's capabilities
information to the sysORTable for the indicated context. An
agentx-Response-PDU is sent in reply with res.error set to
`noError'.
4) さもなければ、マスターエージェントは示された文脈のために副代理店の能力情報をsysORTableに加えます。 'noError'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
7.1.8. Processing the agentx-RemoveAgentCaps-PDU
7.1.8. agentx-RemoveAgentCaps-PDUを処理します。
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext', and the
requested operation fails. Otherwise: The value of res.sysUpTime
is set to the value of sysUpTime.0 for the indicated context.
3) NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントがデフォルト文脈だけを支持するなら、'unsupportedContext'に用意ができているres.errorでagentx応答PDUを返します、そして、要求された操作は失敗します。 そうでなければ: res.sysUpTimeの値は示された文脈のためにsysUpTime.0の値に設定されます。
4) If the combination of a.id and the optional a.context does not
represent a sysORTable entry that was added by this subagent,
during this session, the agentx-Response-PDU is returned with
res.error set to `unknownAgentCaps'.
4) a.イドと任意のa.文脈の組み合わせがこの副代理店によって加えられたsysORTableエントリーを表さないなら、今会期中に、'unknownAgentCaps'に用意ができているres.errorでagentx応答PDUを返します。
5) Otherwise the master agent deletes the corresponding sysORTable
entry and sends in reply the agentx-Response-PDU, with res.error
set to `noError'.
5) さもなければ、マスターエージェントは、対応するsysORTableエントリーを削除して、回答におけるres.errorとagentx応答PDUセットを'noError'に送ります。
7.1.9. Processing the agentx-Close-PDU
7.1.9. agentxの近いPDUを処理します。
When the master agent receives an agentx-Close-PDU, it processes it as follows:
マスターエージェントがagentxの近いPDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています。
Daniele, et. al. Standards Track [Page 52] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[52ページ]。
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、'notOpen'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
3) Otherwise, the master agent closes the AgentX session
as described below. No agentx-Response-PDU is sent.
3) さもなければ、マスターエージェントは以下で説明されるようにAgentXセッションを終えます。 agentx応答PDUを全く送りません。
- All MIB regions that have been registered during this session
are unregistered, as described in 7.1.6.
- 登録されたすべてのMIB領域が7.1で.6に説明されるように今会期中に登録されていないです。
- All index values allocated during this session are freed, as
described in section 7.1.4.
- 今会期中に割り当てられたすべてのインデックス値がセクション7.1.4で説明されるように解放されます。
- All sysORID values that were registered during this session
are removed, as described in section 7.1.8.
- セクション7.1.8で説明されるように今会期中に示されたすべてのsysORID値を取り除きます。
The master agent does not maintain state for closed sessions. If a subagent wishes to re-establish a session after receiving an agentx- Close-PDU, it needs to re-register MIB regions, agent capabilities, etc.
マスターエージェントは非公開審議のために状態を維持しません。 agentxの近いPDUを受けた後に副代理店がセッションを復職させたいなら、それは、MIB領域、エージェント能力などを再登録する必要があります。
7.1.10. Detecting Connection Loss
7.1.10. 接続の損失を検出します。
If a master agent is able to detect (from the underlying transport) that a subagent cannot receive AgentX PDUs, it should close all affected AgentX sessions as described in 7.1.9, step 3).
マスターエージェントがそれを検出できるなら(基本的な輸送から)副代理店がAgentX PDUsを受けることができないで、中で説明されるようにすべての影響を受けるAgentXセッションに閉じるべきである、7.1、.9、ステップ3)。
7.1.11. Processing the agentx-Notify-PDU
7.1.11. agentxにPDUに通知しているのを処理します。
A subagent sending SNMPv1 trap information must map this into (minimally) a value of snmpTrapOID.0, as described in 3.1.2 of RFC 1908 [8].
副代理店送付SNMPv1罠情報はsnmpTrapOID.0の(最少量で)値にこれを写像しなければなりません、中で説明されるように3.1、.2、RFC1908[8]について。
The master agent processes the agentx-Notify-PDU as follows:
The master agent processes the agentx-Notify-PDU as follows:
1) If h.sessionID does not correspond to a currently
established session with this subagent, an agentx-Response-PDU
is sent in reply with res.error set to `notOpen', and
res.sysUpTime set to the value of sysUpTime.0 for the indicated
context.
1) If h.sessionID does not correspond to a currently established session with this subagent, an agentx-Response-PDU is sent in reply with res.error set to `notOpen', and res.sysUpTime set to the value of sysUpTime.0 for the indicated context.
2) The VarBindList is parsed. If it does not contain a value for
sysUpTime.0, the master agent supplies the current value of
sysUpTime.0 for the indicated context. If the next VarBind
(either the first or second VarBind; see section 6.2.10.1) is
not snmpTrapOID.0, the master agent ceases further processing
of the notification.
2) The VarBindList is parsed. If it does not contain a value for sysUpTime.0, the master agent supplies the current value of sysUpTime.0 for the indicated context. If the next VarBind (either the first or second VarBind; see section 6.2.10.1) is not snmpTrapOID.0, the master agent ceases further processing of the notification.
Daniele, et. al. Standards Track [Page 53] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 53] RFC 2257 AgentX January 1998
3) Notifications are sent according to the implementation-specific
configuration of the master agent.
3) Notifications are sent according to the implementation-specific configuration of the master agent.
If SNMPv1 Trap PDUs are generated, the recommended mapping is
as described in RFC 2089 [9].
If SNMPv1 Trap PDUs are generated, the recommended mapping is as described in RFC 2089 [9].
Except in the case of a `notOpen' error as described in (1)
above, no agentx-Response-PDU is sent to the subagent when the
master agent finishes processing the notification.
Except in the case of a `notOpen' error as described in (1) above, no agentx-Response-PDU is sent to the subagent when the master agent finishes processing the notification.
7.1.12. Processing the agentx-Ping-PDU
7.1.12. Processing the agentx-Ping-PDU
When the master agent receives an agentx-Ping-PDU, it processes it as follows:
When the master agent receives an agentx-Ping-PDU, it processes it as follows:
1) An agentx-Response-PDU is created and res.sysUpTime is set to
the value of sysUpTime.0 for the default context.
1) An agentx-Response-PDU is created and res.sysUpTime is set to the value of sysUpTime.0 for the default context.
2) If h.sessionID does not correspond to a currently
established session with this subagent, the agentx-Response-PDU is
sent in reply with res.error set to `notOpen'.
2) If h.sessionID does not correspond to a currently established session with this subagent, the agentx-Response-PDU is sent in reply with res.error set to `notOpen'.
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent
supports only a default context, the agentx-Response-PDU is
returned with res.error set to `unsupportedContext'. Otherwise:
The value of res.sysUpTime is set to the value of sysUpTime.0 for
the indicated context.
3) If the NON_DEFAULT_CONTEXT bit is set, and the master agent supports only a default context, the agentx-Response-PDU is returned with res.error set to `unsupportedContext'. Otherwise: The value of res.sysUpTime is set to the value of sysUpTime.0 for the indicated context.
4) The agentx-Response-PDU is sent, with res.error set to
`noError'.
4) The agentx-Response-PDU is sent, with res.error set to `noError'.
If a subagent does not receive a response to its pings, or if it is able to detect (from the underlying transport) that the master agent is not able to receive AgentX messages, then it eventually must initiate a new AgentX session, re-register its regions, etc.
If a subagent does not receive a response to its pings, or if it is able to detect (from the underlying transport) that the master agent is not able to receive AgentX messages, then it eventually must initiate a new AgentX session, re-register its regions, etc.
7.2. Processing Received SNMP Protocol Messages
7.2. Processing Received SNMP Protocol Messages
When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent applies its access control policy.
When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent applies its access control policy.
In particular, for SNMPv1 or SNMPv2c PDUs, the master agent applies the Elements of Procedure defined in section 4.1 of RFC 1157 [6] that apply to receiving entities. (For other versions of SNMP, the master agent applies the access control policy defined in the Elements of Procedure for those versions.)
In particular, for SNMPv1 or SNMPv2c PDUs, the master agent applies the Elements of Procedure defined in section 4.1 of RFC 1157 [6] that apply to receiving entities. (For other versions of SNMP, the master agent applies the access control policy defined in the Elements of Procedure for those versions.)
Daniele, et. al. Standards Track [Page 54] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 54] RFC 2257 AgentX January 1998
In the SNMPv1 or v2c frameworks, the master agent uses the community string as an index into a local repository of configuration information that may include community profiles or more complex context information.
In the SNMPv1 or v2c frameworks, the master agent uses the community string as an index into a local repository of configuration information that may include community profiles or more complex context information.
If application of the access control policy results in a valid SNMP request PDU, then an SNMP Response-PDU is constructed from information gathered in the exchange of AgentX PDUs between the master agent and one or more subagents. Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents, marshal the subagent responses, and construct an SNMP response PDU.
If application of the access control policy results in a valid SNMP request PDU, then an SNMP Response-PDU is constructed from information gathered in the exchange of AgentX PDUs between the master agent and one or more subagents. Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents, marshal the subagent responses, and construct an SNMP response PDU.
7.2.1. Dispatching AgentX PDUs
7.2.1. Dispatching AgentX PDUs
Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents.
Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents.
Note: In the following procedures, an object identifier is said to be "contained" within an OID range when both of the following are true:
Note: In the following procedures, an object identifier is said to be "contained" within an OID range when both of the following are true:
- The object identifier does not lexicographically precede
the range.
- The object identifier does not lexicographically precede the range.
- The object identifier lexicographically precedes the end
of the range.
- The object identifier lexicographically precedes the end of the range.
General Rules of Procedure
General Rules of Procedure
While processing a particular SNMP request, the master agent may send one or more AgentX PDUs to one or more subagents. The following rules of procedure apply in general to the AgentX master agent. PDU- specific rules are listed in the applicable sections.
While processing a particular SNMP request, the master agent may send one or more AgentX PDUs to one or more subagents. The following rules of procedure apply in general to the AgentX master agent. PDU- specific rules are listed in the applicable sections.
1) Honoring the registry
1) Honoring the registry
Because AgentX supports overlapping registrations, it is possible
for the master agent to obtain a value for a requested varbind
from within multiple registered MIB regions.
Because AgentX supports overlapping registrations, it is possible for the master agent to obtain a value for a requested varbind from within multiple registered MIB regions.
The master agent must ensure that the value (or exception)
actually returned in the SNMP response PDU is taken from the
authoritative region (as defined in section 7.1.5.1).
The master agent must ensure that the value (or exception) actually returned in the SNMP response PDU is taken from the authoritative region (as defined in section 7.1.5.1).
Daniele, et. al. Standards Track [Page 55] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 55] RFC 2257 AgentX January 1998
2) GetNext and GetBulk Processing
2) GetNext and GetBulk Processing
The master agent may choose to send agentx-Get-PDUs while
servicing an SNMP GetNextRequest-PDU. The master agent may choose
to send agentx-Get-PDUs or agentx-GetNext-PDUs while servicing an
SNMP GetBulkRequest-PDU. One possible reason for this would be if
the current iteration has targeted instance-level registrations.
The master agent may choose to send agentx-Get-PDUs while servicing an SNMP GetNextRequest-PDU. The master agent may choose to send agentx-Get-PDUs or agentx-GetNext-PDUs while servicing an SNMP GetBulkRequest-PDU. One possible reason for this would be if the current iteration has targeted instance-level registrations.
The master agent may choose to "scope" the possible instances
returned by a subagent by specifying an ending OID in the
SearchRange. If such scoping is used, typically the ending OID
would be the first lexicographical successor to the target OID
range that was registered by a subagent other than the target
subagent. Regardless of this choice, rule (1) must be obeyed.
The master agent may choose to "scope" the possible instances returned by a subagent by specifying an ending OID in the SearchRange. If such scoping is used, typically the ending OID would be the first lexicographical successor to the target OID range that was registered by a subagent other than the target subagent. Regardless of this choice, rule (1) must be obeyed.
The master agent may require multiple request-response iterations
on the same subagent session, to determine the final value of all
requested variables.
The master agent may require multiple request-response iterations on the same subagent session, to determine the final value of all requested variables.
All AgentX PDUs sent on the session while processing a given SNMP
request must contain identical values of transactionID. Each
different SNMP request processed by the master agent must present
a unique value of transactionID (within the limits of the 32-bit
field) to the session.
All AgentX PDUs sent on the session while processing a given SNMP request must contain identical values of transactionID. Each different SNMP request processed by the master agent must present a unique value of transactionID (within the limits of the 32-bit field) to the session.
3) Number and order of variables sent per AgentX PDU
3) Number and order of variables sent per AgentX PDU
For Get/GetNext/GetBulk operations, at any stage of the possibly
iterative process, the master agent may need to dispatch several
SearchRanges to a particular subagent session. The master agent
may send one, some, or all of the SearchRanges in a single AgentX
PDU.
For Get/GetNext/GetBulk operations, at any stage of the possibly iterative process, the master agent may need to dispatch several SearchRanges to a particular subagent session. The master agent may send one, some, or all of the SearchRanges in a single AgentX PDU.
The master agent must ensure that the correct contents and
ordering of the VarBindList in the SNMP Response-PDU are
maintained.
The master agent must ensure that the correct contents and ordering of the VarBindList in the SNMP Response-PDU are maintained.
The following rules govern the number of VarBinds in a given
AgentX PDU:
The following rules govern the number of VarBinds in a given AgentX PDU:
a) The subagent must support processing of AgentX PDUs
with multiple VarBinds.
a) The subagent must support processing of AgentX PDUs with multiple VarBinds.
b) When processing an SNMP Set request, the master agent
must send all of the VarBinds applicable to a particular
subagent session in a single Test/Set transaction.
b) When processing an SNMP Set request, the master agent must send all of the VarBinds applicable to a particular subagent session in a single Test/Set transaction.
Daniele, et. al. Standards Track [Page 56] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 56] RFC 2257 AgentX January 1998
c) When processing an SNMP Get, GetNext, or GetBulk request,
the master agent may send a single AgentX PDU to the
subagent with all applicable VarBinds, or multiple PDUs with
single VarBinds, or something in between those extremes. The
determination of which method to use in a particular case is
implementation-specific.
c) When processing an SNMP Get, GetNext, or GetBulk request, the master agent may send a single AgentX PDU to the subagent with all applicable VarBinds, or multiple PDUs with single VarBinds, or something in between those extremes. The determination of which method to use in a particular case is implementation-specific.
4) Timeout Values
4) Timeout Values
The master agent chooses a timeout value for each MIB region being
queried, which is
The master agent chooses a timeout value for each MIB region being queried, which is
a) the value specified during registration of the MIB region,
if it was non-zero
a) the value specified during registration of the MIB region, if it was non-zero
b) otherwise, the value specified during establishment of
the session in which this region was subsequently
registered, if that value was non-zero.
b) otherwise, the value specified during establishment of the session in which this region was subsequently registered, if that value was non-zero.
c) otherwise, the master agent's default value
c) otherwise, the master agent's default value
When an AgentX PDU that references multiple MIB regions is
dispatched, the timeout value used for the PDU is the maximum
value of the timeouts so determined for each of the referenced MIB
regions.
When an AgentX PDU that references multiple MIB regions is dispatched, the timeout value used for the PDU is the maximum value of the timeouts so determined for each of the referenced MIB regions.
5) Context
5) Context
If the master agent has determined that a specific non-default
context is associated with the SNMP request PDU, that context is
encoded into the AgentX PDU's context field and the
NON_DEFAULT_CONTEXT bit is set in h.flags.
If the master agent has determined that a specific non-default context is associated with the SNMP request PDU, that context is encoded into the AgentX PDU's context field and the NON_DEFAULT_CONTEXT bit is set in h.flags.
Otherwise, no context Octet String is added to the PDU, and the
NON_DEFAULT_CONTEXT bit is cleared.
Otherwise, no context Octet String is added to the PDU, and the NON_DEFAULT_CONTEXT bit is cleared.
7.2.1.1. agentx-Get-PDU
7.2.1.1. agentx-Get-PDU
Each variable binding in the SNMP request PDU is processed as follows:
Each variable binding in the SNMP request PDU is processed as follows:
(1) Identify the target OID range.
(1) Identify the target OID range.
Within a lexicographically ordered set of OID ranges, valid for
the indicated context, locate the authoritative region that
contains the binding's name.
Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the authoritative region that contains the binding's name.
Daniele, et. al. Standards Track [Page 57] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 57] RFC 2257 AgentX January 1998
(2) If no such OID range exists, the variable binding is not
processed further, and its value is set to `noSuchObject'.
(2) If no such OID range exists, the variable binding is not processed further, and its value is set to `noSuchObject'.
(3) Identify the subagent session in which this region was
registered, termed the target session.
(3) Identify the subagent session in which this region was registered, termed the target session.
(4) If this is the first variable binding to be dispatched over
the target session in a request-response exchange entailed in the
processing of this management request:
(4) If this is the first variable binding to be dispatched over the target session in a request-response exchange entailed in the processing of this management request:
- Create an agentx-Get-PDU for this session, with the header
fields initialized as described above (see 6.1 AgentX PDU
Header).
- Create an agentx-Get-PDU for this session, with the header fields initialized as described above (see 6.1 AgentX PDU Header).
(5) Add a SearchRange to the end of the target session's PDU
for this variable binding.
(5) Add a SearchRange to the end of the target session's PDU for this variable binding.
- The variable binding's name is encoded into the starting OID.
- The variable binding's name is encoded into the starting OID.
- The ending OID is encoded as null.
- The ending OID is encoded as null.
7.2.1.2. agentx-GetNext-PDU
7.2.1.2. agentx-GetNext-PDU
Each variable binding in the SNMP request PDU is processed as follows:
Each variable binding in the SNMP request PDU is processed as follows:
(1) Identify the target OID range.
(1) Identify the target OID range.
Within a lexicographically ordered set of OID ranges, valid for
the indicated context, locate
Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate
a) the authoritative OID range that contains the variable
binding's name and is not a fully qualified instance, or
a) the authoritative OID range that contains the variable binding's name and is not a fully qualified instance, or
b) the authoritative OID range that is the first
lexicographical successor to the variable binding's name.
b) the authoritative OID range that is the first lexicographical successor to the variable binding's name.
(2) If no such OID range exists, the variable binding is not
processed further, and its value is set to `endOfMibView'.
(2) If no such OID range exists, the variable binding is not processed further, and its value is set to `endOfMibView'.
(3) Identify the subagent session in which this region was
registered, termed the target session.
(3) Identify the subagent session in which this region was registered, termed the target session.
(4) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(4) If this is the first variable binding to be dispatched over the target session in a request-response exchange entailed in the processing of this management request:
Daniele, et. al. Standards Track [Page 58] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 58] RFC 2257 AgentX January 1998
- Create an agentx-GetNext-PDU for the session, with
the header fields initialized as described above (see 6.1
AgentX PDU Header).
- Create an agentx-GetNext-PDU for the session, with the header fields initialized as described above (see 6.1 AgentX PDU Header).
(5) Add a SearchRange to the end of the target session's
agentx-GetNext-PDU for this variable binding.
(5) Add a SearchRange to the end of the target session's agentx-GetNext-PDU for this variable binding.
- if (1a) applies, the variable binding's name is encoded
into the starting OID, and the OID's "include" field is set to
0.
- if (1a) applies, the variable binding's name is encoded into the starting OID, and the OID's "include" field is set to 0.
- if (1b) applies, the target OID is encoded into the starting
OID, and its "include" field is set to 1.
- if (1b) applies, the target OID is encoded into the starting OID, and its "include" field is set to 1.
7.2.1.3. agentx-GetBulk-PDU
7.2.1.3. agentx-GetBulk-PDU
(Note: The outline of the following procedure is based closely on section 4.2.3, "The GetBulkRequest-PDU" of RFC 1905 [4]. Please refer to it for details on the format of the SNMP GetBulkRequest-PDU itself.)
(Note: The outline of the following procedure is based closely on section 4.2.3, "The GetBulkRequest-PDU" of RFC 1905 [4]. Please refer to it for details on the format of the SNMP GetBulkRequest-PDU itself.)
Each variable binding in the request PDU is processed as follows:
Each variable binding in the request PDU is processed as follows:
(1) Identify the authoritative target OID range and target session,
exactly as described for the agentx-GetNext-PDU (see 7.2.1.2).
(1) Identify the authoritative target OID range and target session, exactly as described for the agentx-GetNext-PDU (see 7.2.1.2).
(2) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(2) If this is the first variable binding to be dispatched over the target session in a request-response exchange entailed in the processing of this management request:
- Create an agentx-GetBulk-PDU for the session, with
the header fields initialized as described above (see 6.1
AgentX PDU Header).
- Create an agentx-GetBulk-PDU for the session, with the header fields initialized as described above (see 6.1 AgentX PDU Header).
(3) Add a SearchRange to the end of the target session's
agentx-GetBulk-PDU for this variable binding, as described for
the agentx-GetNext-PDU. If the variable binding was a non-
repeater in the original request PDU, it must be a non-repeater
in the agentx-GetBulk-PDU.
(3) Add a SearchRange to the end of the target session's agentx-GetBulk-PDU for this variable binding, as described for the agentx-GetNext-PDU. If the variable binding was a non- repeater in the original request PDU, it must be a non-repeater in the agentx-GetBulk-PDU.
The value of g.max_repetitions in the agentx-GetBulk-PDU may be less than (but not greater than) the value in the original request PDU.
The value of g.max_repetitions in the agentx-GetBulk-PDU may be less than (but not greater than) the value in the original request PDU.
The master agent may make such alterations due to simple sanity checking, optimizations for the current iteration based on the registry, the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint.
The master agent may make such alterations due to simple sanity checking, optimizations for the current iteration based on the registry, the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint.
Daniele, et. al. Standards Track [Page 59] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 59] RFC 2257 AgentX January 1998
7.2.1.4. agentx-TestSet-PDU
7.2.1.4. agentx-TestSet-PDU
AgentX employs test-commit-undo-cleanup phases to achieve "as if simultaneous" semantics of the SNMP SetRequest-PDU within the extensible agent. The initial phase involves the agentx-TestSet-PDU.
AgentX employs test-commit-undo-cleanup phases to achieve "as if simultaneous" semantics of the SNMP SetRequest-PDU within the extensible agent. The initial phase involves the agentx-TestSet-PDU.
Each variable binding in the SNMP request PDU is processed in order, as follows:
Each variable binding in the SNMP request PDU is processed in order, as follows:
(1) Identify the target OID range.
(1) Identify the target OID range.
Within a lexicographically ordered set of OID ranges, valid for
the indicated context, locate the authoritative range that
contains the variable binding's name.
Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the authoritative range that contains the variable binding's name.
(2) If no such OID range exists, this variable binding fails with an
error of `notWritable'. Processing is complete for this request.
(2) If no such OID range exists, this variable binding fails with an error of `notWritable'. Processing is complete for this request.
(3) Identify the single subagent responsible for this OID range,
termed the target subagent, and the applicable session, termed
the target session.
(3) Identify the single subagent responsible for this OID range, termed the target subagent, and the applicable session, termed the target session.
(4) If this is the first variable binding to be dispatched over
the target session in a request-response exchange entailed in the
processing of this management request:
(4) If this is the first variable binding to be dispatched over the target session in a request-response exchange entailed in the processing of this management request:
- create an agentx-TestSet-PDU for the session, with the
header fields initialized as described above (see 6.1 AgentX
PDU Header).
- create an agentx-TestSet-PDU for the session, with the header fields initialized as described above (see 6.1 AgentX PDU Header).
(5) Add a VarBind to the end of the target session's PDU
for this variable binding, as described in section 5.4.
(5) Add a VarBind to the end of the target session's PDU for this variable binding, as described in section 5.4.
Note that all VarBinds applicable to a given session must be sent in
a single agentx-TestSet-PDU.
Note that all VarBinds applicable to a given session must be sent in a single agentx-TestSet-PDU.
7.2.1.5. Dispatch
7.2.1.5. Dispatch
A timeout value is calculated for each PDU to be sent, which is the maximum value of the timeouts determined for each of the PDU's SearchRanges (as described above in 7.2.1 Dispatching AgentX PDUs, item 4). Each pending PDU is mapped (via its h.sessionID value) to a particular transport domain/endpoint, as described in section 8 (Transport Mappings).
A timeout value is calculated for each PDU to be sent, which is the maximum value of the timeouts determined for each of the PDU's SearchRanges (as described above in 7.2.1 Dispatching AgentX PDUs, item 4). Each pending PDU is mapped (via its h.sessionID value) to a particular transport domain/endpoint, as described in section 8 (Transport Mappings).
Daniele, et. al. Standards Track [Page 60] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 60] RFC 2257 AgentX January 1998
7.2.2. Subagent Processing of agentx-Get, GetNext, GetBulk-PDUs
7.2.2. Subagent Processing of agentx-Get, GetNext, GetBulk-PDUs
A conformant AgentX subagent must support the agentx-Get, -GetNext, and -GetBulk PDUs, and must support multiple variables being supplied in each PDU.
A conformant AgentX subagent must support the agentx-Get, -GetNext, and -GetBulk PDUs, and must support multiple variables being supplied in each PDU.
When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns an agentx- Response-PDU.
When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns an agentx- Response-PDU.
The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.index to 0, and the VarBindList to null.
The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.index to 0, and the VarBindList to null.
Each SearchRange in the request PDU's SearchRangeList is processed as described below, and a VarBind is added in the corresponding location of the agentx-Response-PDU's VarbindList. If processing should fail for any reason not described below, res.error is set to `genErr', res.index to the index of the failed SearchRange, the VarBindList is reset to null, and this agentx-Response-PDU is returned to the master agent.
Each SearchRange in the request PDU's SearchRangeList is processed as described below, and a VarBind is added in the corresponding location of the agentx-Response-PDU's VarbindList. If processing should fail for any reason not described below, res.error is set to `genErr', res.index to the index of the failed SearchRange, the VarBindList is reset to null, and this agentx-Response-PDU is returned to the master agent.
7.2.2.1. Subagent Processing of the agentx-Get-PDU
7.2.2.1. Subagent Processing of the agentx-Get-PDU
Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed as follows:
Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed as follows:
(1) The starting OID is copied to v.name.
(1) The starting OID is copied to v.name.
(2) If the starting OID exactly matches the name of a
variable instantiated by this subagent within the indicated
context and session, v.type and v.data are encoded to represent
the variable's syntax and value, as described in section 5.4,
Value Representation.
(2) If the starting OID exactly matches the name of a variable instantiated by this subagent within the indicated context and session, v.type and v.data are encoded to represent the variable's syntax and value, as described in section 5.4, Value Representation.
(3) Otherwise, if the starting OID does not match the object
identifier prefix of any variable instantiated within the
indicated context and session, the VarBind is set to
`noSuchObject', in the manner described in section 5.4, Value
Representation.
(3) Otherwise, if the starting OID does not match the object identifier prefix of any variable instantiated within the indicated context and session, the VarBind is set to `noSuchObject', in the manner described in section 5.4, Value Representation.
(4) Otherwise, the VarBind is set to `noSuchInstance'
in the manner described in section 5.4, Value Representation.
(4) Otherwise, the VarBind is set to `noSuchInstance' in the manner described in section 5.4, Value Representation.
Daniele, et. al. Standards Track [Page 61] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 61] RFC 2257 AgentX January 1998
7.2.2.2. Subagent Processing of the agentx-GetNext-PDU
7.2.2.2. Subagent Processing of the agentx-GetNext-PDU
Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed as follows:
Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed as follows:
(1) The subagent searches for a variable within the
lexicographically ordered list of variable names for all
variables it instantiates (without regard to registration of
regions) within the indicated context and session, for which the
following are all true:
(1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context and session, for which the following are all true:
- if the "include" field of the starting OID is 0, the
variable's name is the closest lexicographical successor to the
starting OID.
- if the "include" field of the starting OID is 0, the variable's name is the closest lexicographical successor to the starting OID.
- if the "include" field of the starting OID is 1, the
variable's name is either equal to, or the closest
lexicographical successor to, the starting OID.
- if the "include" field of the starting OID is 1, the variable's name is either equal to, or the closest lexicographical successor to, the starting OID.
- If the ending OID is not null, the variable's name
lexicographically precedes the ending OID.
- If the ending OID is not null, the variable's name lexicographically precedes the ending OID.
If all of these conditions are met, v.name is set to the located
variable's name. v.type and v.data are encoded to represent the
variable's syntax and value, as described in section 5.4, Value
Representation.
If all of these conditions are met, v.name is set to the located variable's name. v.type and v.data are encoded to represent the variable's syntax and value, as described in section 5.4, Value Representation.
(2) If no such variable exists, v.name is set to the starting OID,
and the VarBind is set to `endOfMibView', in the manner described
in section 5.4, Value Representation.
(2) If no such variable exists, v.name is set to the starting OID, and the VarBind is set to `endOfMibView', in the manner described in section 5.4, Value Representation.
7.2.2.3. Subagent Processing of the agentx-GetBulk-PDU
7.2.2.3. Subagent Processing of the agentx-GetBulk-PDU
A maximum of N + (M * R) VarBinds are returned, where
A maximum of N + (M * R) VarBinds are returned, where
N equals g.non_repeaters,
M equals g.max_repetitions, and
R is (number of SearchRanges in the GetBulk request) - N.
N equals g.non_repeaters, M equals g.max_repetitions, and R is (number of SearchRanges in the GetBulk request) - N.
The first N SearchRanges are processed exactly as for the agentx- GetNext-PDU.
The first N SearchRanges are processed exactly as for the agentx- GetNext-PDU.
If M and R are both non-zero, the remaining R SearchRanges are processed iteratively to produce potentially many VarBinds. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated SearchRange s, such that s is greater than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind is added to the agentx-Response-PDU as follows:
If M and R are both non-zero, the remaining R SearchRanges are processed iteratively to produce potentially many VarBinds. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated SearchRange s, such that s is greater than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind is added to the agentx-Response-PDU as follows:
Daniele, et. al. Standards Track [Page 62] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 62] RFC 2257 AgentX January 1998
1) The subagent searches for a variable within the
lexicographically ordered list of variable names for all
variables it instantiates (without regard to registration of
regions) within the indicated context and session, for which
the following are all true:
1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context and session, for which the following are all true:
- The variable's name is the (i)-th lexicographical successor
to the (N+s)-th requested OID.
- The variable's name is the (i)-th lexicographical successor to the (N+s)-th requested OID.
(Note that if i is 0 and the "include" field is 1, the
variable's name may be equivalent to, or the first
lexicographical successor to, the (N+s)-th requested OID.)
(Note that if i is 0 and the "include" field is 1, the variable's name may be equivalent to, or the first lexicographical successor to, the (N+s)-th requested OID.)
- If the ending OID is not null, the variable's name
lexicographically precedes the ending OID.
- If the ending OID is not null, the variable's name lexicographically precedes the ending OID.
If all of these conditions are met, v.name is set to the
located variable's name. v.type and v.data are encoded to
represent the variable's syntax and value, as described in
section 5.4, Value Representation.
If all of these conditions are met, v.name is set to the located variable's name. v.type and v.data are encoded to represent the variable's syntax and value, as described in section 5.4, Value Representation.
2) If no such variable exists, the VarBind is set to
`endOfMibView' as described in section 5.4, Value
Representation. v.name is set to v.name of the (N+((i-
2)*R)+s)-th VarBind unless i is currently 1, in which case it
is set to the value of the starting OID in the (N+s)-th
SearchRange.
2) If no such variable exists, the VarBind is set to `endOfMibView' as described in section 5.4, Value Representation. v.name is set to v.name of the (N+((i- 2)*R)+s)-th VarBind unless i is currently 1, in which case it is set to the value of the starting OID in the (N+s)-th SearchRange.
Note that further iterative processing should stop if
Note that further iterative processing should stop if
- For any iteration i, all s values of v.type are
`endOfMibView'.
- For any iteration i, all s values of v.type are `endOfMibView'.
- An AgentX transport constraint or other
implementation-specific constraint is reached.
- An AgentX transport constraint or other implementation-specific constraint is reached.
7.2.3. Subagent Processing of agentx-TestSet, -CommitSet, -UndoSet,
-CleanupSet-PDUs
7.2.3. Subagent Processing of agentx-TestSet, -CommitSet, -UndoSet, -CleanupSet-PDUs
A conformant AgentX subagent must support the agentx-TestSet, -CommitSet, -UndoSet, and -CleanupSet PDUs, and must support multiple variables being supplied in each PDU.
A conformant AgentX subagent must support the agentx-TestSet, -CommitSet, -UndoSet, and -CleanupSet PDUs, and must support multiple variables being supplied in each PDU.
These four PDUs are used to collectively perform the indicated management operation. An agentx-Response-PDU is sent in reply to each of the PDUs, to inform the master agent of the state of the operation.
These four PDUs are used to collectively perform the indicated management operation. An agentx-Response-PDU is sent in reply to each of the PDUs, to inform the master agent of the state of the operation.
Daniele, et. al. Standards Track [Page 63] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 63] RFC 2257 AgentX January 1998
The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', and res.index to 0.
The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', and res.index to 0.
These Response-PDUs do not contain a VarBindList.
These Response-PDUs do not contain a VarBindList.
7.2.3.1. Subagent Processing of the agentx-TestSet-PDU
7.2.3.1. Subagent Processing of the agentx-TestSet-PDU
Upon the subagent's receipt of an agentx-TestSet-PDU, each VarBind in the PDU is validated until they are all successful, or until one fails, as described in section 4.2.5 of RFC 1905 [4]. The subagent validates variables with respect to the context and session indicated in the testSet-PDU.
Upon the subagent's receipt of an agentx-TestSet-PDU, each VarBind in the PDU is validated until they are all successful, or until one fails, as described in section 4.2.5 of RFC 1905 [4]. The subagent validates variables with respect to the context and session indicated in the testSet-PDU.
If each VarBind is successful, the subagent has a further responsibility to ensure the availability of all resources (memory, write access, etc.) required for successfully carrying out a subsequent agentx-CommitSet operation. If this cannot be guaranteed, the subagent should set res.error to `resourceUnavailable'.
If each VarBind is successful, the subagent has a further responsibility to ensure the availability of all resources (memory, write access, etc.) required for successfully carrying out a subsequent agentx-CommitSet operation. If this cannot be guaranteed, the subagent should set res.error to `resourceUnavailable'.
As a result of this validation step, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values:
As a result of this validation step, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values:
noError (0),
genErr (5),
noAccess (6),
wrongType (7),
wrongLength (8),
wrongEncoding (9),
wrongValue (10),
noCreation (11),
inconsistentValue (12),
resourceUnavailable (13),
notWritable (17),
inconsistentName (18)
noError (0), genErr (5), noAccess (6), wrongType (7), wrongLength (8), wrongEncoding (9), wrongValue (10), noCreation (11), inconsistentValue (12), resourceUnavailable (13), notWritable (17), inconsistentName (18)
If this value is not `noError', the res.index field must be set to the index of the VarBind for which validation failed.
If this value is not `noError', the res.index field must be set to the index of the VarBind for which validation failed.
Implementation of rigorous validation code may be one of the most demanding aspects of subagent development. Implementors are strongly encouraged to do this right, so as to avoid if at all possible the extensible agent's having to return `commitFailed' or `undoFailed' during subsequent processing.
Implementation of rigorous validation code may be one of the most demanding aspects of subagent development. Implementors are strongly encouraged to do this right, so as to avoid if at all possible the extensible agent's having to return `commitFailed' or `undoFailed' during subsequent processing.
Daniele, et. al. Standards Track [Page 64] RFC 2257 AgentX January 1998
Daniele, et. al. Standards Track [Page 64] RFC 2257 AgentX January 1998
7.2.3.2. Subagent Processing of the agentx-CommitSet-PDU
7.2.3.2. Subagent Processing of the agentx-CommitSet-PDU
The agentx-CommitSet-PDU indicates that the subagent should actually perform (as described in the post-validation sections of 4.2.5 of RFC 1905 [4]) the management operation indicated by the previous TestSet-PDU. After carrying out the management operation, the subagent sends in reply an agentx-Response-PDU whose res.error field is set to one of the following (SNMPv2 SMI) values:
agentx-CommitSet-PDUは、副代理店が実際に働くべきであるのを示します。(4.2人のポスト合法化部で管理操作が前のTestSet-PDUで示した.5RFC1905[4])について説明するので。 管理操作を行った後に、副代理店は回答でres.error分野が以下の(SNMPv2 SMI)値の1つに設定されるagentx応答PDUを送ります:
noError (0),
commitFailed (14)
noError(0)、commitFailed(14)
If this value is `commitFailed', the res.index field must be set to the index of the VarBind for which the operation failed. Otherwise res.index is set to 0.
この値が'commitFailed'であるなら、res.index fieldは操作が失敗したVarBindのインデックスに用意ができなければなりません。 さもなければ、res.indexは0に用意ができています。
7.2.3.3. Subagent Processing of the agentx-UndoSet-PDU
7.2.3.3. agentx-UndoSet-PDUの副代理店処理
The agentx-UndoSet-PDU indicates that the subagent should undo the management operation requested in a preceding CommitSet-PDU. The undo process is as described in section 4.2.5 of RFC 1905 [4].
agentx-UndoSet-PDUは、副代理店が前のCommitSet-PDUで要求された管理操作を元に戻すべきであるのを示します。 アンドゥプロセスが.5セクション4.2RFC1905[4]で説明されるようにあります。
After carrying out the undo process, the subagent sends in reply an agentx-Response-PDU whose res.index field is set to 0, and whose res.error field is set to one of the following (SNMPv2 SMI) values:
アンドゥプロセスを行った後に、副代理店は回答でres.index fieldが0に用意ができて、res.error分野が以下の(SNMPv2 SMI)値の1つに設定されるagentx応答PDUを送ります:
noError (0),
undoFailed (15)
noError(0)、undoFailed(15)
If this value is `undoFailed', the res.index field must be set to the index of the VarBind for which the operation failed. Otherwise res.index is set to 0.
この値が'undoFailed'であるなら、res.index fieldは操作が失敗したVarBindのインデックスに用意ができなければなりません。 さもなければ、res.indexは0に用意ができています。
This PDU also signals the end of processing of the management operation initiated by the previous TestSet-PDU. The subagent should release resources, etc. as described in section 7.2.3.4.
また、このPDUは前のTestSet-PDUによって開始された管理操作の処理の終わりに合図します。 副代理店はリソースを発表するべきであり、セクション7.2.3における説明されるとしてのなどは.4です。
7.2.3.4. Subagent Processing of the agentx-CleanupSet-PDU
7.2.3.4. agentx-CleanupSet-PDUの副代理店処理
The agentx-CleanupSet-PDU signals the end of processing of the management operation requested in the previous TestSet-PDU. This is an indication to the subagent that it may now release any resources it may have reserved in order to carry out the management request.
agentx-CleanupSet-PDUは前のTestSet-PDUで要求された管理操作の処理の終わりに合図します。 これは副代理店への現在管理要求を行うために予約したどんなリソースも発表するかもしれないという指示です。
No response is sent by the subagent.
副代理店は応答を全く送りません。
Daniele, et. al. Standards Track [Page 65] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[65ページ]。
7.2.4. Master Agent Processing of AgentX Responses
7.2.4. AgentX応答のマスターエージェント処理
The master agent now marshals all subagent AgentX response PDUs and builds an SNMP response PDU. In the next several subsections, the initial processing of all subagent AgentX response PDUs is described, followed by descriptions of subsequent processing for each specific subagent Response.
マスターエージェントは、現在、すべての副代理店AgentX応答PDUsを整列させて、SNMP応答PDUを造ります。 次のいくつかの小区分では、すべての副代理店AgentX応答PDUsの初期の処理は説明されます、それぞれの特定の副代理店Responseのためのその後の処理の記述があとに続いていて。
7.2.4.1. Common Processing of All AgentX Response PDUs
7.2.4.1. すべてのAgentX応答PDUsの一般的な処理
1) If a subagent does not respond within the timeout interval for
this dispatch, it is treated as if the subagent had returned
`genErr' and processed as described below.
1) 副代理店がタイムアウト間隔中にこの発信のために応じないなら、それは、以下で説明されるようにまるで副代理店が'genErr'を返したかのように扱われて、処理されます。
A timeout may be due to a variety of reasons, and does not
necessarily denote a failed or malfunctioning subagent. As such,
the master agent's response to a subagent timeout is
implementation-specific, but with the following constraint:
タイムアウトは、さまざまな理由のためにあるかもしれなくて、必ず失敗されるか誤動作副代理店を指示するというわけではありません。 実装特有ですがそういうものとして以下の規制で副代理店タイムアウトへのマスターエージェントの応答:
A subagent that times out on three consecutive requests is
considered unable to respond, and the master agent must close
the AgentX session as described in 7.1.9, step (2).
3に連続した回が要求する副代理店が応じることができないと考えられて、マスターエージェントが中で説明されるようにAgentXセッションを終えなければならない、7.1、.9、(2)を踏んでください。
2) Otherwise, the h.packetID, h.sessionID, and h.transactionID
fields of the AgentX response PDU are used to correlate subagent
responses. If the response does not pertain to this SNMP
operation, it is ignored.
2) さもなければ、AgentX応答PDUのh.packetID、h.sessionID、およびh.transactionID分野は、副代理店応答を関連させるのに使用されます。 応答がこのSNMP操作に関しないなら、それは無視されます。
3) Otherwise, the responses are processed jointly to form the SNMP
response PDU.
3) さもなければ、応答は、SNMP応答PDUを形成するために共同で処理されます。
7.2.4.2. Processing of Responses to agentx-Get-PDUs
7.2.4.2. agentxがPDUsを手に入れることへの応答の処理
After common processing of the subagent's response to an agentx-Get- PDU (see 7.2.4.1 above), processing continues with the following steps:
見てください。-agentxへの副代理店の応答を処理して、一般的であった後に得てください、-、PDU、(7.2 .4 上の.1) 処理は以下のステップを続行します:
1) For any received AgentX response PDU, if res.error is not
`noError', the SNMP response PDU's error code is set to this
value, and its error index to the index of the variable binding
corresponding to the failed VarBind in the subagent's AgentX
response PDU.
1) どんな容認されたAgentX応答PDUにおいても、SNMP応答PDUのエラーコードはres.errorが'noError'でないなら、この値、および副代理店のAgentX応答PDUにおける失敗したVarBindに対応する変項束縛のインデックスへのその誤りインデックスに設定されます。
All other AgentX response PDUs received due to processing this
SNMP request are ignored. Processing is complete; the SNMP
Response PDU is ready to be sent (see section 7.2.5, Sending the
SNMP Response-PDU).
このSNMPが要求する処理のため受け取られた他のすべてのAgentX応答PDUsは無視されます。 処理は完全です。 SNMP Response PDUは送る準備ができています(セクション7.2.5、Sending SNMP Response-PDUを見てください)。
Daniele, et. al. Standards Track [Page 66] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[66ページ]。
2) Otherwise, the content of each VarBind in the AgentX response PDU
is used to update the corresponding variable binding in the SNMP
Response-PDU.
2) さもなければ、AgentX応答PDUにおけるそれぞれのVarBindの内容は、SNMP Response-PDUで対応する変項束縛をアップデートするのに使用されます。
7.2.4.3. Processing of Responses to agentx-GetNext-PDU and
agentx-GetBulk-PDU
7.2.4.3. agentx-GetNext-PDUとagentx-GetBulk-PDUへの応答の処理
After common processing of the subagent's response to an agentx- GetNext-PDU or agentx-GetBulk-PDU (see 7.2.4.1 above), processing continues with the following steps:
見てください。agentx- GetNext-PDUかagentx-GetBulk-PDUへの副代理店の応答の一般的な処理の後、(7.2 .4 上の.1) 処理は以下のステップを続行します:
1) For any received AgentX response PDU, if res.error is not
`noError', the SNMP response PDU's error code is set to this
value, and its error index to the index of the VarBind
corresponding to the failed VarBind in the subagent's AgentX
response PDU.
1) どんな容認されたAgentX応答PDUにおいても、SNMP応答PDUのエラーコードはres.errorが'noError'でないなら、この値、および副代理店のAgentX応答PDUにおける失敗したVarBindに対応するVarBindのインデックスへのその誤りインデックスに設定されます。
All other AgentX response PDUs received due to processing this
SNMP request are ignored. Processing is complete; the SNMP
response PDU is ready to be sent (see section 7.2.5, Sending the
SNMP Response PDU).
このSNMPが要求する処理のため受け取られた他のすべてのAgentX応答PDUsは無視されます。 処理は完全です。 SNMP応答PDUは送る準備ができています(セクション7.2.5、Sending SNMP Response PDUを見てください)。
2) Otherwise, the content of each VarBind in the AgentX response
PDU is used to update the corresponding VarBind in the SNMP
response PDU.
2) さもなければ、AgentX応答PDUにおけるそれぞれのVarBindの内容は、SNMP応答PDUで対応するVarBindをアップデートするのに使用されます。
After all expected AgentX response PDUs have been processed, if any VarBinds still contain the value `endOfMibView' in their v.type fields, processing must continue:
結局予想されたAgentX応答PDUsは処理されました、どんなVarBindsも彼らのv.タイプ分野にまだ値の'endOfMibView'を保管しています、と処理は続けなければなりません:
3) A new iteration of AgentX request dispatching is initiated
(as described in section 7.2.1.1), in which only those VarBinds
whose v.type is `endOfMibView' are processed.
3) AgentX要求の急ぎの新しい繰り返し((処理されます)v.タイプが'endOfMibView'であるそれらのVarBindsだけ)は開始されます(セクション7.2.1で.1について説明するので)。
4) For each such VarBind, a target OID range is identified
which is the lexicographical successor to the target OID range
for this VarBind on the last iteration. The target subagent is
the one that registered the target OID range. The target session
is the one in which the target OID range was registered.
4) そのような各VarBindに関しては、目標OID範囲は特定されます(最後の繰り返しでのこのVarBindのための目標OID範囲の辞書編集の後継者です)。 目標副代理店は目標OID範囲を示したものです。 目標セッションは目標OID範囲が示されたものです。
If an agentx-GetNext- or GetBulk-PDU is being dispatched, the
starting OID in the SearchRanges is set to the target OID range,
and its "include" field is set to 1.
agentx-GetNextかGetBulk-PDUが派遣されるなら、SearchRangesの始めのOIDは目標OID範囲に用意ができています、そして、「包含」分野は1に設定されます。
5) The value of transactionID must be identical to the value
used during the previous iteration.
5) transactionIDの値は前の繰り返しの間に使用される値と同じであるに違いありません。
Daniele, et. al. Standards Track [Page 67] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[67ページ]。
6) The AgentX PDUs are sent to the subagent(s), and the responses
are received and processed according to the steps described in
section 7.2.4.
6) AgentX PDUsを副代理店に送って、セクション7.2.4で説明されたステップに従って、応答は、受けられて、処理されます。
7) This process continues iteratively until a complete SNMP
Response-PDU has been built, or until there remain no target OID
range lexicographical successors.
7) 完全なSNMP Response-PDUが造られたか、またはどんな目標OID範囲辞書編集の後継者も残らないまで、このプロセスは繰り返しに持続します。
7.2.4.4. Processing of Responses to agentx-TestSet-PDUs
7.2.4.4. agentx-TestSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx- TestSet-PDU (see 7.2.4.1 above), processing continues with the further exchange of AgentX PDUs. The value of h.transactionID in the agentx-CommitSet, -UndoSet, and -CleanupSet-PDUs must be identical to the value sent in the testSet-PDU.
見てください。agentx- TestSet-PDUへの副代理店の応答の一般的な処理の後、(7.2 .4 上の.1) 処理はAgentX PDUsのさらなる交換を続行します。 agentx-CommitSet、-UndoSet、および-CleanupSet-PDUsのh.transactionIDの値はtestSet-PDUで送られた値と同じであるに違いありません。
The state transitions and PDU sequences are depicted in section 7.3.
状態遷移とPDU系列はセクション7.3で表現されます。
1) If any target subagent's response is not `noError', all other
agentx-Response-PDUs received due to processing this SNMP request
are ignored.
1) どんな目標副代理店の応答も'noError'でないなら、このSNMPが要求する処理のため受け取られた他のすべてのagentx応答PDUsが無視されます。
An agentx-CleanupSet-PDU is sent to each target subagent that has
been sent a agentx-TestSet-PDU.
agentx-TestSet-PDUが送られたそれぞれの目標副代理店にagentx-CleanupSet-PDUを送ります。
Processing is complete; the SNMP response PDU is constructed as
described below in 7.2.4.6.
処理は完全です。 応答PDUが組み立てられるSNMPは以下で7.2で.6に.4について説明しました。
2) Otherwise an agentx-CommitSet-PDU is sent to each target
subagent.
2) さもなければ、それぞれの目標副代理店にagentx-CommitSet-PDUを送ります。
7.2.4.5. Processing of Responses to agentx-CommitSet-PDUs
7.2.4.5. agentx-CommitSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx- CommitSet-PDU (see 7.2.4.1 above), processing continues with the following steps:
見てください。agentx- CommitSet-PDUへの副代理店の応答の一般的な処理の後、(7.2 .4 上の.1) 処理は以下のステップを続行します:
1) If any response is not `noError', all other
agentx-Response-PDUs received due to processing this SNMP request
are ignored.
1) 何か応答も'noError'でないなら、このSNMPが要求する処理のため受け取られた他のすべてのagentx応答PDUsが無視されます。
An agentx-UndoSet-PDU is sent to each target subagent that has
been sent a agentx-CommitSet-PDU. All other subagents are sent a
agentx-CleanupSet-PDU.
agentx-CommitSet-PDUが送られたそれぞれの目標副代理店にagentx-UndoSet-PDUを送ります。 他のすべての副代理店にagentx-CleanupSet-PDUを送ります。
2) Otherwise an agentx-CleanupSet-PDU is sent to each target
subagent. Processing is complete; the SNMP response PDU is
constructed as described below in 7.2.4.6.
2) さもなければ、それぞれの目標副代理店にagentx-CleanupSet-PDUを送ります。 処理は完全です。 応答PDUが組み立てられるSNMPは以下で7.2で.6に.4について説明しました。
Daniele, et. al. Standards Track [Page 68] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[68ページ]。
7.2.4.6. Processing of Responses to agentx-UndoSet-PDUs
7.2.4.6. agentx-UndoSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx- UndoSet-PDU (see 7.2.4.1 above), processing continues with the following steps:
見てください。agentx- UndoSet-PDUへの副代理店の応答の一般的な処理の後、(7.2 .4 上の.1) 処理は以下のステップを続行します:
1) If any response is not `noError' the SNMP response
PDU's error code is set to this value, and its error index to the
index of the VarBind corresponding to the failed VarBind in the
agentx-TestSet-PDU.
1) 何か応答も'noError'でないなら、SNMP応答PDUのエラーコードはこの値、およびagentx-TestSet-PDUの失敗したVarBindに対応するVarBindのインデックスへのその誤りインデックスに設定されます。
Otherwise the SNMP response PDU's error code is set to `noError'
and its error index to 0.
さもなければ、SNMP応答PDUのエラーコードは'noError'と0へのその誤りインデックスに設定されます。
7.2.5. Sending the SNMP Response-PDU
7.2.5. SNMP応答-PDUを送ります。
Once the processing described in sections 7.2.1 - 7.2.4 is complete, there is an SNMP response PDU available. The master agent now implements the Elements of Procedure for the applicable version of the SNMP protocol in order to encapsulate the PDU into a message, and transmit it to the originator of the SNMP management request. Note that this may involve altering the PDU contents (for instance, to replace the original VarBinds if an error condition is to be returned).
かつてのセクション7.2.1で説明された処理--、7.2、.4、PDU利用可能なSNMP応答は、完全であり、あります。 メッセージにPDUをカプセル化して、経営者側が要求するSNMPの創始者にそれを伝えて、マスターエージェントは現在、SNMPプロトコルの適切なバージョンのためにProcedureのElementsを実装します。 これが、PDUコンテンツを変更することを伴うかもしれないことに注意してください(例えば、オリジナルを置き換えるには、VarBindsはエラー条件であるなら返されることになっています)。
The response PDU may also be altered in order to support the SNMP version 1 framework. In such cases the required mapping is that defined in RFC 2089 [9]. (Note in particular that the rules for handling Counter64 syntax may require re-sending AgentX GetBulk or GetNext PDUs until a VarBind of suitable syntax is returned.)
また、応答PDUは、SNMPがバージョン1フレームワークであるとサポートするために変更されるかもしれません。 そのような場合必要なマッピングはRFC2089[9]でそんなに定義されています。 (取り扱いCounter64構文のための規則が、適当な構文のVarBindを返すまでAgentX GetBulkかGetNext PDUsを再送するのを必要とするかもしれないことに特に注意してください。)
7.2.6. MIB Views
7.2.6. MIB視点
AgentX subagents are not aware of MIB views, since view information is not contained in AgentX PDUs.
視点情報がAgentX PDUsに含まれていないので、AgentX副代理店はMIB視点を意識していません。
As stated above, the descriptions of procedures in section 7 of this memo are not intended to constrain the internal architecture of any conformant implementation. In particular, the master agent procedures described in sections 7.2.1 and 7.2.4 may be altered so as to optimize AgentX exchanges when implementing MIB views.
上に述べられているように、このメモのセクション7の手順の記述がどんなconformant実装の内部のアーキテクチャも抑制することを意図しません。 特に、マスターエージェント手順はセクション7.2で.1について説明しました、そして、7.2に、.4は、MIBに視点を実装するとき、AgentX交換を最適化するために変更されるかもしれません。
Such optimizations are beyond the scope of this memo. But note that section 7.2.3 defines subagent behavior in such a way that alteration of SearchRanges may be used in such optimizations.
そのような最適化はこのメモの範囲を超えています。 しかし、セクション7.2.3がSearchRangesの変更がそのような最適化に使用されるかもしれないような方法で副代理店の振舞いを定義することに注意してください。
Daniele, et. al. Standards Track [Page 69] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[69ページ]。
7.3. State Transitions
7.3. 状態遷移
State diagrams are presented from the master agent's perspective for transport connection and session establishment, and from the subagent's perspective for Set transaction processing.
州のダイヤグラムは輸送接続とセッション設立のためのマスターエージェントの見解と、Setトランザクション処理のための副代理店の見解から提示されます。
7.3.1. Set Transaction States
7.3.1. トランザクション州を設定してください。
The following table presents, from the subagent's perspective, the state transitions involved in Set transaction processing:
以下のテーブルは副代理店の見解からSetトランザクション処理にかかわる状態遷移を提示します:
STATE
+----------------+--------------+---------+--------+--------
| A | B | C | D | E
| (Initial | TestOK | Commit | Test | Commit
| State) | | OK | Fail | Fail
| | | | |
EVENT | | | | |
---------+----------------+--------------+---------+--------+--------
| 7.2.3.1 | | | |
Receive | All varbinds | | | |
TestSet | OK? | X | X | X | X
PDU | Yes ->B | | | |
| No ->D | | | |
---------+----------------+--------------+---------+--------+--------
| | 7.2.3.2 | | |
Receive | | NoError? | | |
Commit- | X | Yes ->C | X | X | X
Set PDU | | No ->E | | |
---------+----------------+--------------+---------+--------+--------
Receive | | | 7.2.3.3 | |7.2.4.5
UndoSet | X | X | ->done | X | ->done
PDU | | | | |
---------+----------------+--------------+---------+--------+--------
Receive | | 7.2.4.4 | 7.2.3.4 |7.2.4.4 |
Cleanup- | X | ->done | ->done | ->done | X
Set PDU | | | | |
---------+----------------+--------------+---------+--------+--------
Session | | rollback | undo | |
Loss | ->done | ->done | ->done | ->done | ->done
---------+----------------+--------------+---------+--------+--------
状態+----------------+--------------+---------+--------+-------- | A| B| C| D| E| (TestOK| 公約してください| テストしてください| |頭文字をつけてください、そして、| 状態を遂行してください) | | OK| 失敗してください。| 失敗してください。| | | | | イベント| | | | | ---------+----------------+--------------+---------+--------+-------- | 7.2.3.1 | | | | 受信してください。| すべてのvarbinds| | | | TestSet| OK? | X| X| X| X PDU| はい>B| | | | | >がありませんD。| | | | ---------+----------------+--------------+---------+--------+-------- | | 7.2.3.2 | | | 受信してください。| | NoError? | | | 公約してください。| X| はい>C| X| X| XセットPDU| | >がありませんE。| | | ---------+----------------+--------------+---------+--------+-------- 受信してください。| | | 7.2.3.3 | |7.2.4.5 UndoSet| X| X| -行われた>。| X| -PDUが行われた>。| | | | | ---------+----------------+--------------+---------+--------+-------- 受信してください。| | 7.2.4.4 | 7.2.3.4 |7.2.4.4 | クリーンアップ| X| -行われた>。| -行われた>。| -行われた>。| XセットPDU| | | | | ---------+----------------+--------------+---------+--------+-------- セッション| | ロールバック| アンドゥ| | 損失| -行われた>。| -行われた>。| -行われた>。| -行われた>。| -行われた>。---------+----------------+--------------+---------+--------+--------
There are three possible sequences that a subagent may follow for a particular set transaction:
副代理店が特定のセットトランザクションのために従うかもしれない3つの可能な順序があります:
1) TestSet CommitSet CleanupSet
2) TestSet CommitSet UndoSet
3) TestSet CleanupSet
1) TestSet CommitSet CleanupSet2) TestSet CommitSet UndoSet3) TestSet CleanupSet
Daniele, et. al. Standards Track [Page 70] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[70ページ]。
Note that a single PDU sequence may result in multiple paths through the finite state machine (FSM). For example, the sequence
ただ一つのPDU系列が有限状態機械(FSM)を通した複数の経路をもたらすかもしれないことに注意してください。 例えば、系列
TestSet CommitSet UndoSet
TestSet CommitSet UndoSet
may walk through either of these two state sequences:
これらの2のどちらかを通した散歩が系列を述べますように:
(initial) TestOK CommitOK (done)
(initial) TestOK CommitFail (done)
(初期)のTestOK CommitOK(する)の(初期)のTestOK CommitFail(します)
7.3.2 Transport Connection States
7.3.2 輸送接続州
The following table presents, from the master agent's perspective, the state transitions involved in transport connection setup and teardown:
状態遷移がマスターエージェントの見解から輸送接続設定にかかわった以下のテーブルプレゼントと分解:
Daniele, et. al. Standards Track [Page 71] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[71ページ]。
STATE
+--------------+--------------
| A | B
| No transport | Transport
| | connected
| |
EVENT | |
----------------+--------------+--------------
Transport | |
connect | ->B | X
indication | |
----------------+--------------+--------------
Receive | | if duplicate
Open-PDU | | session id,
| | reject, else
| X | establish
| | session
| |
| | ->B
----------------+--------------+--------------
Receive | | if matching
Response-PDU | | session id,
| | feed to that
| X | session's FSM
| | else ignore
| |
| | ->B
----------------+--------------+--------------
Receive other | | if matching
PDUs | | session id,
| | feed to that
| X | session's FSM
| | else reject
| |
| | ->B
----------------+--------------+--------------
Transport | |notify all
disconnect | |sessions on
indication | X |this transport
| |
| | ->A
----------------+--------------+--------------
状態+--------------+-------------- | A| B| 輸送がありません。| 輸送| | 接続されます。| | イベント| | ----------------+--------------+-------------- 輸送| | 接続してください。| ->B| X指示| | ----------------+--------------+-------------- 受信してください。| | オープン-PDUをコピーしてくださいなら| | セッションイド| | ほかに廃棄物| X| 設立します。| | セッション| | | | ->B----------------+--------------+-------------- 受信してください。| | Response-PDUを合わせます。| | セッションイド| | それに食べてください。| X| セッションのFSM| | ほか、無視| | | | ->B----------------+--------------+-------------- 別に受信してください。| | PDUsを合わせます。| | セッションイド| | それに食べてください。| X| セッションのFSM| | ほかの廃棄物| | | | ->B----------------+--------------+-------------- 輸送| |すべての分離に通知してください。| |指示のセッション| X|この輸送| | | | ->A----------------+--------------+--------------
Daniele, et. al. Standards Track [Page 72] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[72ページ]。
7.3.3 Session States
7.3.3 セッション州
The following table presents, from the master agent's perspective, the state transitions involved in session setup and teardown:
以下のテーブルはマスターエージェントの見解からセッションセットアップと分解にかかわる状態遷移を提示します:
STATE
+-------------+----------------
| A | B
| No session | Session
| | established
EVENT | |
---------------+-------------+----------------
| 7.1.1 |
Receive | | X
Open PDU | ->B |
---------------+-------------+----------------
| | 7.1.9
Receive | X |
Close PDU | | ->A
---------------+-------------+----------------
Receive | | 7.1.5
Register PDU | X |
| | ->B
---------------+-------------+----------------
Receive | | 7.1.6
Unregister | X |
PDU | | ->B
---------------+-------------+----------------
Receive | |
Get PDU | |
GetNext PDU | |
GetBulk PDU | X | X
TestSet PDU | |
CommitSet PDU | |
UndoSet PDU | |
CleanupSet PDU | |
---------------+-------------+----------------
Receive | | 7.1.11
Notify PDU | X |
| | ->B
---------------+-------------+----------------
Receive Ping | | 7.1.12
PDU | X |
| | ->B
---------------+-------------+----------------
(continued next page)
状態+-------------+---------------- | A| B| セッションがありません。| セッション| | 確立したEVENT| | ---------------+-------------+---------------- | 7.1.1 | 受信してください。| | X開いているPDU| ->B| ---------------+-------------+---------------- | | 7.1.9 受信してください。| X| PDUを閉じてください。| | ->A---------------+-------------+---------------- 受信してください。| | 7.1.5 PDUを登録してください。| X| | | ->B---------------+-------------+---------------- 受信してください。| | 7.1.6 Unregister| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | PDUを手に入れてください。| | GetNext PDU| | GetBulk PDU| X| X TestSet PDU| | CommitSet PDU| | UndoSet PDU| | CleanupSet PDU| | ---------------+-------------+---------------- 受信してください。| | 7.1.11 PDUに通知してください。| X| | | ->B---------------+-------------+---------------- ピングを受けてください。| | 7.1.12 PDU| X| | | ->B---------------+-------------+---------------- (次のページを続けています)
Daniele, et. al. Standards Track [Page 73] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[73ページ]。
---------------+-------------+----------------
Receive | | 7.1.2
IndexAllocate | X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.4
IndexDeallocate| X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.7
AddAgentxCaps | X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.8
RemoveAgentxCap| X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.2.4
Response PDU | X |
| | ->B
---------------+-------------+----------------
Receive | |
Other PDU | X | X
---------------+-------------+----------------
---------------+-------------+---------------- 受信してください。| | 7.1.2 IndexAllocate| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.4 IndexDeallocate| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.7 AddAgentxCaps| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.8 RemoveAgentxCap| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.2.4 応答PDU| X| | | ->B---------------+-------------+---------------- 受信してください。| | 他のPDU| X| X---------------+-------------+----------------
8. Transport Mappings
8. 輸送マッピング
The same AgentX PDU formats, encodings, and elements of procedure are used regardless of the underlying transport.
手順の同じAgentX PDU形式、encodings、および要素は基本的な輸送にかかわらず使用されます。
8.1. AgentX over TCP
8.1. TCPの上のAgentX
8.1.1. Well-known Values
8.1.1. よく知られる値
The master agent accepts TCP connection requests for the well-known port 705. Subagents connect to the master agent using this port number.
マスターエージェントはウェルノウンポート705を求めるTCP接続要求を受け入れます。 このポートナンバーを使用することで副代理店はマスターエージェントに接します。
8.1.2. Operation
8.1.2. 操作
Once a TCP connection has been established, the AgentX peers use this connection to carry all AgentX PDUs. Multiple AgentX sessions may be established using the same TCP connection. AgentX PDUs are sent within an AgentX session. AgentX peers are responsible for mapping the h.sessionID to a particular TCP connection.
TCP接続がいったん確立されると、AgentX同輩は、すべてのAgentX PDUsを運ぶのにこの接続を使用します。 複数のAgentXセッションが、同じTCP接続を使用することで確立されるかもしれません。 AgentXセッション以内にAgentX PDUsを送ります。 AgentX同輩は特定のTCP接続にh.sessionIDを写像するのに責任があります。
All AgentX PDUs are presented individually to the TCP, to be sent as the data portion of a TCP PDU.
TCP PDUのデータ部として送るために個別にすべてのAgentX PDUsをTCPに寄贈します。
Daniele, et. al. Standards Track [Page 74] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[74ページ]。
8.2. AgentX over UNIX-domain Sockets
8.2. UNIX-ドメインソケットの上のAgentX
Many (BSD-derived) implementations of the UNIX operating system support the UNIX pathname address family (AF_UNIX) for socket communications. This provides a convenient method of sending and receiving data between processes on the same host.
Unixオペレーティングシステムの多くの(BSDによって派生する)の実装が、ソケットコミュニケーションのためにUNIXパス名アドレスがファミリー(AF_UNIX)であるとサポートします。 これは同じホストの上で送受信データの便利な方法をプロセスの間に提供します。
Mapping AgentX to this transport is useful for environments that
この輸送にAgentXを写像するのが環境の役に立つ、それ
- wish to guarantee subagents are running on the same
managed node as the master agent, and where
- 副代理店がマスターエージェント、およびどこと同じ管理されたノードで動いているかを保証することを願ってください。
- sockets provide better performance than TCP or UDP,
especially in the presence of heavy network I/O
- ソケットは特に重いネットワーク入出力があるときTCPかUDPより良い性能を提供します。
8.2.1. Well-known Values
8.2.1. よく知られる値
The master agent creates a well-known UNIX-domain socket endpoint called "/var/agentx/master". (It may create other, implementation- specific endpoints.)
マスターエージェントは"/var/agentx/master"と呼ばれるよく知られるUNIX-ドメインソケット終点を作成します。 (それは他の、そして、実装特有の終点を作成するかもしれません。)
This endpoint name uses the character set encoding native to the managed node, and represents a UNIX-domain stream (SOCK_STREAM) socket.
この終点名は、管理されたノード固有の文字集合コード化を使用して、UNIX-ドメインストリーム(SOCK_STREAM)ソケットを表します。
8.2.2. Operation
8.2.2. 操作
Once a connection has been established, the AgentX peers use this connection to carry all AgentX PDUs.
接続がいったん確立されると、AgentX同輩は、すべてのAgentX PDUsを運ぶのにこの接続を使用します。
Multiple AgentX sessions may be established using the same connection. AgentX PDUs are sent within an AgentX session. AgentX peers are responsible for mapping the h.sessionID to a particular connection.
複数のAgentXセッションが、同じ接続を使用することで確立されるかもしれません。 AgentXセッション以内にAgentX PDUsを送ります。 AgentX同輩はh.sessionIDを特定の接続に写像するのに責任があります。
All AgentX PDUs are presented individually to the socket layer, to be sent in the data stream.
データ・ストリームで送るために個別にすべてのAgentX PDUsをソケットレイヤーに寄贈します。
9. Security Considerations
9. セキュリティ問題
This memo defines a protocol between two processing entities, one of which (the master agent) is assumed to perform authentication of received SNMP requests and to control access to management information. The master agent performs these security operations independently of the other processing entity (the subagent).
このメモは2つの処理実体((マスターエージェント)が受信されたSNMP要求の認証を実行して、経営情報へのアクセスを制御すると思われるもの)の間のプロトコルを定義します。 マスターエージェントはもう片方の処理実体(副代理店)の如何にかかわらずこれらのセキュリティ操作を実行します。
Daniele, et. al. Standards Track [Page 75] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[75ページ]。
Security considerations require three questions to be answered:
セキュリティ問題は、3つの質問が答えられるのを必要とします:
1. Is a particular subagent allowed to initiate a session with a
particular master agent?
1. 特定の副代理店は特定のマスターエージェントとのセッションを開始できますか?
2. During an AgentX session, is any SNMP security-related
information (for example, community names) passed from the
master agent to the subagent?
2. AgentXセッションの間、何かSNMPのセキュリティ関連の情報(例えば、共同体名)がマスターエージェントから副代理店まで通過されますか?
3. During an AgentX session, what part of the MIB tree is this
subagent allowed to register?
3. AgentXセッションの間、この副代理店はMIB木のどんな部分に登録できますか?
The answer to the third question is: A subagent can register any subtree (subject to AgentX elements of procedure, section 7.1.5). Currently there is no access control mechanism defined in AgentX. A concern here is that a malicious subagent that registers an unauthorized "sensitive" subtree, could see modification requests to those objects, or by giving its own clever answer to NMS queries, could cause the NMS to do something that leads to information disclosure or other damage.
3番目の質問の答えは以下の通りです。 副代理店はどんな下位木(手順のAgentX要素を条件としたセクション7.1.5)も登録できます。 現在、AgentXで定義されたアクセス管理機構が全くありません。 NMSが権限のない「敏感な」下位木を登録して、それらのオブジェクト、またはそれ自身のNMS質問の賢明な答えを与えることによって変更要求を見ることができるだろう悪意がある副代理店で情報公開か他の損害に通じる何かをするかもしれないという関心がここにあります。
The answer to the second question is: No.
2番目の質問の答えは以下の通りです。 いいえ
Now we can answer the first question. AgentX does not contain a mechanism for authorizing/refusing session initiations. Thus, controlling subagent access to the master agent may only be done at a lower layer (e.g., transport).
今、私たちは最初の質問に答えることができます。 AgentXはセッション開始を権限を与えるか、または拒否するためのメカニズムを含んでいません。 したがって、マスターエージェントへの副代理店アクセスは下層(例えば、輸送)で制御されるだけであるかもしれません。
An AgentX subagent can connect to a master agent using either a network transport mechanism (e.g., TCP), or a "local" mechanism (e.g., shared memory, named pipes).
ネットワーク移送機構(例えば、TCP)か「地方」のメカニズム(例えば、共有メモリ、名前付きパイプ)のどちらかを使用することでAgentX副代理店はマスターエージェントに接できます。
In the case where a local transport mechanism is used and both subagent and master agent are running on the same host, connection authorization can be delegated to the operating system features. The answer to the first security question then becomes: "If and only if the subagent has sufficient privileges, then the operating system will allow the connection".
ローカル運送メカニズムが使用されていて、副代理店とマスターエージェントの両方が同じホストで走っている場合では、接続承認をオペレーティングシステム機能へ代表として派遣することができます。 次に、最初のセキュリティ質問の答えはなります: 「副代理店に十分な特権がある場合にだけオペレーティングシステムが接続を許す、」
If a network transport is used, currently there is no inherent security. Transport Layer Security or SSL could be used to control subagent connections, but that is beyond the scope of this document.
ネットワーク輸送が使用されているなら、現在、どんな固有のセキュリティもありません。 副代理店接続を監督するのに輸送Layer SecurityかSSLを使用できましたが、それはこのドキュメントの範囲を超えています。
Thus it is recommended that subagents always run on the same host as the master agent and that operating system features be used to ensure that only properly authorized subagents can establish connections to the master agent.
したがって、副代理店がいつもマスターエージェントと同じホストで走って、オペレーティングシステム機能が適切に認可された副代理店しかマスターエージェントに関係を樹立できないのを保証するのに使用されるのは、お勧めです。
Daniele, et. al. Standards Track [Page 76] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[76ページ]。
10. Acknowledgements
10. 承認
The initial development of this memo was heavily influenced by the DPI 2.0 specification RFC 1592 [7].
このメモの初期の開発はDPI2.0仕様RFC1592[7]によって大いに影響を及ぼされました。
This document was produced by the IETF Agent Extensibility (AgentX) Working Group, and benefited especially from the contributions of the following working group members:
このドキュメントは、IETFエージェントExtensibility(AgentX)作業部会によって起こされて、特に以下のワーキンググループのメンバーの貢献の利益を得ました:
David Battle, Uri Blumenthal, Jeff Case, Maria Greene, Dave
Keeney, Harmen van der Linde, Bob Natale, Randy Presuhn, Aleksey
Romanov, Don Ryan, and Juergen Schoenwaelder.
デヴィッドBattle、ユリ・ブルーメンソル、ジェフCase、マリア・グリーン、デーヴ・キーニー、Harmenはderリンデ、ボブNatale、ランディPresuhn、アレックセイ・ロマーノフ、ドン・ライアン、およびユルゲンSchoenwaelderをバンに積みます。
The AgentX Working Group is chaired by:
AgentX作業部会は以下によってまとめられます。
Bob Natale ACE*COMM Corporation 704 Quince Orchard Road Gaithersburg MD 20878
ボブNatale ACE*COMM社704のマルメロオーチャード・ロードゲイザースバーグMD 20878
Phone: +1-301-721-3000 Fax: +1-301-721-3001 EMail: bnatale@acecomm.com
以下に電話をしてください。 +1-301-721-3000 Fax: +1-301-721-3001 メールしてください: bnatale@acecomm.com
11. Authors' and Editor's Addresses
11. 作者とエディタのアドレス
Mike Daniele Digital Equipment Corporation 110 Spit Brook Rd Nashua, NH 03062
マイクダニエルDEC110はブルック・第ナッシュア、ニューハンプシャー 03062に痰唾を吐きました。
Phone: +1-603-881-1423 EMail: daniele@zk3.dec.com
以下に電話をしてください。 +1-603-881-1423 メールしてください: daniele@zk3.dec.com
Bert Wijnen IBM Professional Services Watsonweg 2 1423 ND Uithoorn The Netherlands
バートWijnen IBMの専門家はWatsonweg2第1423オイトホルンオランダにサービスを提供します。
Phone: +31-79-322-8316 EMail: wijnen@vnet.ibm.com
以下に電話をしてください。 +31-79-322-8316 メールしてください: wijnen@vnet.ibm.com
Daniele, et. al. Standards Track [Page 77] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[77ページ]。
Dale Francisco (editor) Cisco Systems 150 Castilian Dr Goleta CA 93117
デールフランシスコ(エディタ)シスコシステムズ150カスティリャのゴレタカリフォルニア博士 93117
Phone: +1-805-961-3642 Fax: +1-805-961-3600 EMail: dfrancis@cisco.com
以下に電話をしてください。 +1-805-961-3642 Fax: +1-805-961-3600 メールしてください: dfrancis@cisco.com
12. References
12. 参照
[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] 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]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[3] 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]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[4] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[5] 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.
[5]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。
[6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May
1990.
[6] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A. and G. Waters,
"Simple Network Management Protocol: Distributed Protocol
Interface, Version 2.0", RFC 1592, March 1994.
[7]WijnenとB.と大工、G.、カラン、K.とSehgalとA.とG.水域、「簡単なネットワークマネージメントは以下について議定書の中で述べます」。 1994年3月にRFC1592をプロトコルインタフェース、バージョン2インチ分配しました。
[8] 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]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネットの標準のNetwork Management Frameworkのバージョン1とバージョン2の間の共存」、RFC1908(1996年1月)。
[9] Wijnen, B. and D. Levi, "V2ToV1: Mapping SNMPv2 onto SNMPv1
Within a Bilingual SNMP Agent", RFC 2089, January 1997.
[9]Wijnen、B.、およびD.レビ、「V2ToV1:」 「バイリンガルSNMPエージェントの中でSNMPv2をSNMPv1に写像する」RFC2089、1997年1月。
Daniele, et. al. Standards Track [Page 78] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[78ページ]。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1904, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための順応声明は(SNMPv2)について議定書の中で述べます」、RFC1904、1996年1月。
[11] McCloghrie, K. and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC 1573, January 1994.
[11]McCloghrieとK.とF.Kastenholz、「MIB-IIのインタフェースグループの発展」、RFC1573、1994年1月。
[12] Case, J., "FDDI Management Information Base", RFC 1285,
January 1992.
[12] ケース、J.、「FDDI管理情報ベース」、RFC1285、1992年1月。
[13] Application MIB Working Group, Krupczak, C., and J. Saperia,
"Definitions of System-Level Managed Objects for Applications",
draft-ietf-applmib-sysapplmib-08.txt, 15 Apr 1997.
[13] アプリケーションのMIB作業部会、Krupczak、C.、およびJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、草稿-ietf-applmib-sysapplmib-08.txt(1997年4月15日)。
Daniele, et. al. Standards Track [Page 79] RFC 2257 AgentX January 1998
etダニエル、アル。 規格はAgentX1998年1月にRFC2257を追跡します[79ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Daniele, et. al. Standards Track [Page 80]
etダニエル、アル。 標準化過程[80ページ]
一覧
スポンサーリンク
