RFC2922 日本語訳
2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. (Format: TXT=66830 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Bierman
Request for Comments: 2922 Cisco Systems, Inc.
Category: Informational K. Jones
Nortel Networks
September 2000
Biermanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2922年のシスコシステムズInc.カテゴリ: 情報のK.ジョーンズノーテルは2000年9月をネットワークでつなぎます。
Physical Topology MIB
物理的なトポロジーMIB
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは物理的なトポロジー識別と発見を管理するのに使用される管理オブジェクトについて説明します。
Table of Contents
目次
1 The SNMP Network Management Framework ............................2 2 Overview .........................................................3 2.1 Terms ..........................................................3 2.2 Design Goals ...................................................5 3 Topology Framework ...............................................6 3.1 Devices and Topology Agents ....................................6 3.2 Topology Mechanisms ............................................7 3.3 Future Considerations ..........................................7 4 Physical Topology MIB ............................................7 4.1 Persistent Identifiers .........................................8 4.2 Relationship to Entity MIB .....................................8 4.3 Relationship to Interfaces MIB .................................9 4.4 Relationship to RMON-2 MIB .....................................9 4.5 Relationship to Bridge MIB .....................................9 4.6 Relationship to Repeater MIB ...................................9 4.7 MIB Structure .................................................10 4.7.1 ptopoData Group .............................................10 4.7.2 ptopoGeneral Group ..........................................10 4.7.3 ptopoConfig Group ...........................................10 4.8 Physical Topology MIB Definitions .............................10
1 SNMPネットワークマネージメントフレームワーク…2 2概要…3 2.1の用語…3 2.2 目標を設計してください…5 3トポロジーフレームワーク…6 3.1台のデバイスとトポロジーのエージェント…6 3.2 トポロジーメカニズム…7 3.3の将来の問題…7 4の物理的なトポロジーMIB…7 4.1の永続的な識別子…8 実体MIBとの4.2関係…8 インタフェースMIBとの4.3関係…9 RMON-2 MIBとの4.4関係…9 ブリッジMIBとの4.5関係…9 リピータMIBとの4.6関係…9 4.7 MIB構造…10 4.7 .1 ptopoDataは分類します…10 4.7 .2 ptopoGeneralは分類します…10 4.7 .3 ptopoConfigは分類します…10 4.8 物理的なトポロジーMIB定義…10
Bierman & Jones Informational [Page 1] RFC 2922 Physical Topology MIB September 2000
物理的な[1ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
5 Intellectual Property ...........................................27 6 Acknowledgements ................................................28 7 References ......................................................28 8 Security Considerations .........................................30 9 Authors' Addresses ..............................................31 10 Full Copyright Statement .......................................32
5知的所有権…27 6つの承認…28 7つの参照箇所…28 8 セキュリティ問題…30 9人の作者のアドレス…31 10の完全な著作権宣言文…32
1. The SNMP Network Management Framework
1. SNMPネットワークマネージメントフレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[RFC2571]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for
the purpose of management. The first version of this
Structure of Management Information (SMI) is called SMIv1
and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC
1212 [RFC1212] and RFC 1215 [RFC1215]. The second version,
called SMIv2, is described in STD 58, RFC 2578 [RFC2578],
STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]、およびRFC1215[RFC1215]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されます。
o Message protocols for transferring management information.
The first version of the SNMP message protocol is called
SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A
second version of the SNMP message protocol, which is not an
Internet standards track protocol, is called SNMPv2c and
described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The
third version of the message protocol is called SNMPv3 and
described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC
2574 [RFC2574].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[RFC1157]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[RFC1901]とRFC1906[RFC1906]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]でSNMPv3と呼ばれて、説明されます。
o Protocol operations for accessing management information.
The first set of protocol operations and associated PDU
formats is described in STD 15, RFC 1157 [RFC1157]. A
second set of protocol operations and associated PDU formats
is described in RFC 1905 [RFC1905].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[RFC1905]で説明されます。
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism
described in RFC 2575 [RFC2575].
o RFC2573[RFC2573]で説明された1セットの基礎的応用と視点ベースのアクセス管理機構はRFC2575で[RFC2575]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
Bierman & Jones Informational [Page 2] RFC 2922 Physical Topology MIB September 2000
物理的な[2ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
2. Overview
2. 概要
There is a need for a standardized means of representing the physical network connections pertaining to a given management domain. The Physical Topology MIB (PTOPO-MIB) provides a standard way to identify connections between network ports and to discover network addresses of SNMP agents containing management information associated with each port.
与えられた管理ドメインに関係する物理ネットワーク接続の代理をする標準化された手段の必要があります。 Physical Topology MIB(PTOPO-MIB)はネットワークポートの間の接続を特定して、各ポートに関連している経営情報を含むSNMPエージェントのネットワーク・アドレスを発見する標準の方法を提供します。
A topology mechanism is used to discover the information required by the PTOPO-MIB. There is a need for a standardized topology mechanism to increase the likelihood of multi-vendor interoperability of such physical topology management information. The PTOPO-MIB does not, however, specify or restrict the discovery mechanism(s) used for an implementation of the PTOPO-MIB. Topology mechanisms exist for certain media types (such as FDDI) and proprietary mechanisms exist for other media such as shared media Ethernet, switched Ethernet, and Token Ring. Rather than specifying mechanisms for each type of technology, the PTOPO-MIB allows co-existence of multiple topology mechanisms. The required objects of the PTOPO-MIB define the core requirements for any topology mechanism.
トポロジーメカニズムは、情報がPTOPO-MIBが必要であると発見するのに使用されます。 標準化されたトポロジーメカニズムがそのような物理的なトポロジー経営情報のマルチベンダ相互運用性の可能性を広げる必要があります。 しかしながら、PTOPO-MIBはPTOPO-MIBの実装に使用される発見メカニズムを、指定もしませんし、制限もしません。 トポロジーメカニズムはあるメディアタイプ(FDDIなどの)のために存在しています、そして、独占メカニズムは共有されたメディアイーサネットや、切り換えられたイーサネットや、Token Ringなどの他のメディアのために存在しています。 それぞれのタイプの技術にメカニズムを指定するよりむしろ、PTOPO-MIBは複数のトポロジーメカニズムの共存を許容します。PTOPO-MIBの必要なオブジェクトはどんなトポロジーメカニズムのためのコア要件も定義します。
The scope of the physical topology (PTOPO) mechanism is the identification of connections between two network ports. Network addresses of SNMP agents containing management information associated with each port can also be identified.
物理的なトポロジー(PTOPO)メカニズムの範囲は2つのネットワークポートの間の接続の識別です。 また、各ポートに関連している経営情報を含むSNMPエージェントのネットワーク・アドレスを特定できます。
2.1. Terms
2.1. 用語
Some terms are used throughout this document:
いくつかの用語がこのドキュメント中で使用されます:
Physical Topology
Physical topology represents the topology model for layer 1 of
the OSI stack - the physical layer. Physical topology consists
of identifying the devices on the network and how they are
physically interconnected. By definition of this document,
physical topology does not imply a physical relationship
between ports on the same device. Other means exist for
物理的なTopology PhysicalトポロジーはOSIスタックの層1のためにトポロジーモデルの代理をします--物理的な層。 ネットワークのデバイスとそれらがどのように物理的にインタコネクトされるかを特定するのから物理的なトポロジーは成ります。 定義上、このドキュメントでは、物理的なトポロジーは同じデバイスの上のポートの間の物理的な関係を含意しません。 手段が存在するもう一方
Bierman & Jones Informational [Page 3] RFC 2922 Physical Topology MIB September 2000
物理的な[3ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
determining these relationships (e.g., Entity MIB [RFC2737])
exist for determining these relationships. Note that physical
topology is independent of logical topology, which associates
ports based on higher layer attributes, such as network layer
address.
これらの関係(例えば、Entity MIB[RFC2737])がこれらの関係を決定するために存在することを決定します。 物理的なトポロジーが論理的トポロジーから独立しているというメモ。(そのメモはネットワーク層アドレスなどの、より高い層の属性に基づくポートを関連づけます)。
Chassis
A chassis is a physical component which contains other physical
components. It is identified by an entPhysicalEntry with an
entPhysicalClass value of 'chassis(3)' and an
entPhysicalContainedIn value of zero. A chassis identifier
consists of a globally unique SnmpAdminString.
筐体A筐体は他の物理的構成要素を含む物理的構成要素です。 それは'筐体(3)'のentPhysicalClass値とゼロのentPhysicalContainedIn値でentPhysicalEntryによって特定されます。 筐体識別子はグローバルにユニークなSnmpAdminStringから成ります。
Local Chassis
The particular chassis containing the SNMP agent implementing
the PTOPO MIB.
地方のChassis、PTOPO MIBを実装するSNMPエージェントを含む特定の筐体。
Port
A port is a physical component which can be connected to
another port through some medium. It is identified by an
entPhysicalEntry with an entPhysicalClass value of 'port(10)'.
A port identifier consists of an SnmpAdminString which must be
unique within the context of the chassis which contains the
port.
ポートAポートは媒体を通して別のポートに接続できる物理的構成要素です。 それは'ポート(10)'のentPhysicalClass値でentPhysicalEntryによって特定されます。 ポート識別子はポートを含む筐体の文脈の中でユニークであるに違いないSnmpAdminStringから成ります。
Connection Endpoint
A connection endpoint consists of a physical port, which is
contained within a single physical chassis.
接続Endpoint A接続終点は物理的なポートから成ります。(それは、ただ一つの物理的な筐体の中に含まれています)。
Connection Endpoint Identifier
A connection endpoint is identified by a globally unique
chassis identifier and a port identifier unique within the
associated chassis.
接続Endpoint Identifier A接続終点はグローバルにユニークな筐体識別子と関連筐体の中でユニークなポート識別子によって特定されます。
Connection
A connection consists of two physical ports, and the attached
physical medium, configured for the purpose of transferring
network traffic between the ports. A connection is identified
by its endpoint identifiers.
接続A接続は物理的なポート、および添付の物理的な媒体がポートの間のネットワークトラフィックを移す目的のために構成した2から成ります。 接続は終点識別子によって特定されます。
Non-local Connection
A connection for which neither endpoint is located on the local
chassis.
どちらの終点も地方の筐体に位置していない非地元のConnection A接続。
Bierman & Jones Informational [Page 4] RFC 2922 Physical Topology MIB September 2000
物理的な[4ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
Cloud
A cloud identifies a portion of the topology for which
insufficient information is known to completely infer the
interconnection of devices that make up that portion of the
topology.
雲のA雲は不十分な情報がトポロジーのその部分を作るデバイスのインタコネクトを完全に推論するのが知られているトポロジーの部分を特定します。
2.2. Design Goals
2.2. デザイン目標
Several factors influenced the design of this physical topology function:
いくつかの要素がこの物理的なトポロジー機能のデザインに影響を及ぼしました:
- Simplicity
The physical topology discovery function should be as simple as
possible, exposing only the information needed to identify
connection endpoints and the SNMP agent(s) associated with each
connection endpoint.
- 物理的なトポロジー発見機能ができるだけ簡単であるべきであり、必要である情報だけを暴露している簡単さはそれぞれの接続終点に関連づけられた接続終点とSNMPエージェントを特定します。
- Completeness
At least one standard discovery protocol capable of supporting
the standard physical topology MIB must be defined. Multi-
vendor interoperability will not be achievable unless a simple
and extensible discovery protocol is available. However, the
PTOPO MIB should not specify or restrict the topology discovery
mechanisms an agent can use.
- 標準の物理的なトポロジーがMIBであるとサポートすることができる完全性Atの最少のものの標準の発見プロトコルを定義しなければなりません。 簡単で広げることができる発見プロトコルが利用可能でない場合、マルチベンダー相互運用性は達成可能にならないでしょう。 しかしながら、PTOPO MIBはエージェントが使用できるトポロジー発見メカニズムを指定するはずがありませんし、また制限するはずがありません。
- No Functional Overlap
Existing standard MIBs should be utilized whenever possible.
Physical topology information is tightly coupled to
functionality found in the Interfaces MIB [RFC2233] and Entity
MIB [RFC2737]. New physical topology MIB objects should not
duplicate these MIBs.
- 可能であるときはいつも、どんなFunctional Overlap Existingの標準のMIBsも利用するべきではありません。 物理的なトポロジー情報はInterfaces MIB[RFC2233]とEntity MIB[RFC2737]で見つけられた機能性への密結合です。 新しい物理的なトポロジーMIBオブジェクトはこれらのMIBsをコピーするはずがありません。
- Identifier Stability
Connection endpoint identifiers must be persistent (i.e. stable
across device reboots). Dynamic primary key objects like
ifIndex and entPhysicalIndex are not suitable for table indices
in a physical topology MIB that is replicated and distributed
throughout a managed system.
- 識別子Stability Connection終点識別子は永続的であるに違いありません(すなわち、デバイスリブートの向こう側に安定した)。 ifIndexとentPhysicalIndexのようなダイナミックな主キーオブジェクトは管理されたシステム中で模写されて、分配される物理的なトポロジーMIBのテーブルインデックスリストに適していません。
- Identifier Flexibility
Persistent string-based component identifiers should be
supported from many sources. Chassis identifiers may be found
in the Entity MIB [RFC2737], and port identifiers may be found
in the Interfaces MIB [RFC2233] or Entity MIB [RFC2737].
- 識別子のFlexibility Persistentのストリングベースのコンポーネント識別子は多くのソースからサポートされるべきです。 筐体識別子はEntity MIB[RFC2737]で見つけられるかもしれません、そして、ポート識別子はInterfaces MIB[RFC2233]かEntity MIB[RFC2737]で見つけられるかもしれません。
Bierman & Jones Informational [Page 5] RFC 2922 Physical Topology MIB September 2000
物理的な[5ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
- Partial Topology Support
Physical topology data for remote components may only be
partially available to an agent. An enumerated INTEGER
hierarchy of component identifier types allows for incomplete
physical connection identifier information to be substituted
with secondary information such as unicast source MAC address
or network address associated with a particular port. A PTOPO
Agent maintains information derived from the 'best' source of
information for each connection. If a 'better' identifier
source is detected, the PTOPO entries are updated accordingly.
It is an implementation specific matter whether a PTOPO agent
replaces 'old' entries or retains them, however an agent must
remove information known to be incorrect.
- エージェントだけに、リモートコンポーネントのための部分的なTopology Support Physicalトポロジーデータは部分的に利用可能であるかもしれません。 コンポーネント識別子タイプの列挙されたINTEGER階層構造は、不完全な物理接続識別子情報がユニキャストソースMACアドレスか指定港に関連しているネットワーク・アドレスのセカンダリ情報で代入されるのを許容します。 PTOPOエージェントは各接続のために'最も良い'情報源から得られた情報を保守します。 'より良い'識別子ソースを検出するなら、それに従って、PTOPOエントリーをアップデートします。 PTOPOエージェントが'古い'エントリーを取り替えるか、またはそれらを保有するかが、実装の特定の問題である、しかしながら、エージェントは不正確であることが知られている情報を取り除かなければなりません。
- Low Polling Impact
Physical topology polling should be minimized through
techniques such as TimeFiltered data tables (from RMON-2
[RFC2021]), and last-change notifications.
- 低いPolling Impact Physicalトポロジー世論調査はTimeFilteredデータテーブル(RMON-2[RFC2021]からの)や、最後の変更届出書などのテクニックで最小にされるべきです。
3. Topology Framework
3. トポロジーフレームワーク
This section describes the physical topology framework in detail.
このセクションは詳細に物理的なトポロジーフレームワークについて説明します。
3.1. Devices and Topology Agents
3.1. デバイスとトポロジーのエージェント
The network devices, along with their physical connectivity, make up the physical topology. Some of these devices (but maybe not all) provide management agents that report their local physical topology information to a manager via the physical topology MIB.
ネットワークデバイスはそれらの物理的な接続性と共に物理的なトポロジーを作ります。 これらのいくつかのデバイス(しかし、多分すべてでない)が物理的なトポロジーMIBを通して地元の物理的なトポロジー情報をマネージャに報告する管理エージェントを提供します。
These devices include communication infrastructure devices, such as hubs, switches, and routers, as well as 'leaf' devices such as workstations, printers, and servers. Generally, user data passes through infrastructure devices while leaf devices are sources and sinks of data. Both types of devices may implement the physical topology MIB, although implementation within leaf devices is much less critical.
これらのデバイスはハブや、スイッチや、ルータなどのコミュニケーションインフラストラクチャデバイス、およびワークステーションや、プリンタや、サーバなどの'葉'デバイスを含んでいます。 一般に、葉のデバイスは、データのソースと流し台ですが、利用者データはインフラストラクチャデバイスを通り抜けます。 葉のデバイスの中の実装はあまりそれほど重要ではありませんが、両方のタイプのデバイスは、物理的なトポロジーがMIBであると実装するかもしれません。
Each managed device collects physical topology information from the network, based on the topology mechanism(s) it is configured to use. The data represents this agent's local view of the physical network. Part of the topology data collected must include the identification of other local agents which may contain additional topology information. The definition of 'local' varies based on the topology mechanism or mechanisms being used.
それぞれの管理されたデバイスは使用するのが構成されているトポロジーメカニズムに基づいてネットワークから物理的なトポロジー情報を集めます。 データはこのエージェントの物理ネットワークのローカルの視点を表します。 データが集めたトポロジーの一部が追加トポロジー情報を含むかもしれない他の地元のエージェントの識別を含まなければなりません。 '地方'の定義は使用されるトポロジーメカニズムかメカニズムに基づいて異なります。
Bierman & Jones Informational [Page 6] RFC 2922 Physical Topology MIB September 2000
物理的な[6ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
3.2. Topology Mechanisms
3.2. トポロジーメカニズム
A topology mechanism is a means, possibly requiring some sort of protocol, by which devices determine topology information. The topology mechanism must provide sufficient information to populate the MIB described later in this document.
ことによると、ある種のプロトコル(デバイスはトポロジー情報を決定する)を必要として、トポロジーメカニズムは手段です。 トポロジーメカニズムは、後で本書では説明されたMIBに居住するために十分な情報を提供しなければなりません。
Topology mechanisms can be active or passive. Active mechanisms require a device to send and receive topology protocol packets. These packets provide the device ID of the source of the packet and may also indicate out which port the packet was transmitted. When receiving these packets, devices typically are required to identify on which port that packet was received.
トポロジーメカニズムは、アクティブであるか、または受け身である場合があります。 アクティブなメカニズムは、トポロジープロトコルパケットを送って、受けるためにデバイスを必要とします。 これらのパケットは、パケットの源のIDをデバイスに供給して、また、パケットがどのポートから伝えられたかを示すかもしれません。 これらのパケットを受けるとき、デバイスが、そのパケットがどのポートの上で受け取られたかを特定するのに通常必要です。
Passive mechanisms take advantage of data on the network to populate the topology MIB. By maintaining a list of device identifiers seen on each port of all devices in a network, it is possible to populate the PTOPO-MIB.
受け身のメカニズムは、トポロジーMIBに居住するのにネットワークに関するデータを利用します。 すべてのデバイスの各ポートの上でネットワークで見られたデバイス識別子のリストを維持することによって、PTOPO-MIBに居住するのは可能です。
Many instances of a particular topology mechanism may be in use on a given network, and many different mechanisms may be employed. In some cases, multiple mechanisms may overlap across part of the physical topology with individual ports supporting more than one topology mechanism. In general, this simply allows the port to collect more robust topology information. Agents may need to be configured so that they know which mechanism(s) are in use on any given portion of the network.
特定のトポロジーメカニズムの多くのインスタンスが与えられたネットワークで使用中であるかもしれません、そして、多くの異なったメカニズムが使われるかもしれません。 いくつかの場合、複数のメカニズムが物理的なトポロジーの一部の向こう側に1つ以上のトポロジーメカニズムをサポートする個々のポートに重なるかもしれません。 一般に、これで、ポートは単により強健なトポロジー情報を集めることができます。 エージェントが、構成される必要があるかもしれないので、彼らは、どのメカニズムが何かネットワークの与えられた部分で使用中であるかを知っています。
Most topology mechanisms need to be bounded to a subset of the network to contain their impact on the network and limit the size of topology tables maintained by the agent. Topology mechanisms are often naturally bounded by the media on which they run (e.g. FDDI topology mechanism) or by routers in the network that intentionally block the mechanism from crossing into other parts of the network.
ほとんどのトポロジーメカニズムが、トポロジーテーブルのサイズがエージェントで維持したネットワークと限界にそれらの影響を含むのにネットワークの部分集合に境界がある必要があります。 トポロジーメカニズムはしばしば自然に制限されて、それらがそんなに故意に(例えば、FDDIトポロジーメカニズム)かネットワークにおけるルータで稼働するメディアが、メカニズムがネットワークの他の部分と交差するのを妨げるということです。
3.3. Future Considerations
3.3. 将来の問題
While the framework presented here is focused on physical topology, it may well be that the topology mechanisms and MIB described could be extended to include logical topology information as well. That is not a focus of this memo.
ここに提示されたフレームワークが物理的なトポロジーに焦点を合わせられる間、たぶん、また、論理的トポロジー情報を含むようにメカニズムとMIBが説明したトポロジーを広げることができたということでしょう。 それはこのメモの焦点ではありません。
4. Physical Topology MIB
4. 物理的なトポロジーMIB
This section describes and defines the Physical Topology MIB.
このセクションは、Physical Topology MIBを説明して、定義します。
Bierman & Jones Informational [Page 7] RFC 2922 Physical Topology MIB September 2000
物理的な[7ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
4.1. Persistent Identifiers
4.1. 永続的な識別子
The PTOPO MIB utilizes non-volatile identifiers to distinguish individual chassis and port components. These identifiers are associated with external objects in order to relate topology information to the existing managed objects.
PTOPO MIBは、個々の筐体を区別して、コンポーネントを移植するのに非揮発性の識別子を利用します。 これらの識別子は、既存の管理オブジェクトにトポロジー情報に関連するように外部のオブジェクトに関連しています。
In particular, an object from the Entity MIB [RFC2737] or Interfaces MIB [RFC2233] can be used as the 'reference-point' for a connection component identifier.
特に、接続コンポーネント識別子に'基準点'としてEntity MIB[RFC2737]かInterfaces MIB[RFC2233]からのオブジェクトを使用できます。
The Physical Topology MIB uses two identifier types pertaining to the PTOPO MIB:
Physical Topology MIBはPTOPO MIBに関係する2つの識別子タイプを使用します:
- globally unique chassis identifiers.
- グローバルにユニークな筐体識別子。
- port identifiers; unique only within the chassis which contains
the port.
- 識別子を移植してください。 ポートを含む筐体だけの中でユニークです。
Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes in length, This supports flexible naming conventions and constrains the non-volatile storage requirements for an agent.
識別子がOCTET STRINGsとして保存されて、Thisはエージェントのためにフレキシブルな命名規則をサポートして、非揮発性記憶装置要件を抑制します。(OCTET STRINGsは長さ32バイトに制限されます)。
4.2. Relationship to Entity MIB
4.2. 実体MIBとの関係
The first version of the Entity MIB [RFC2037] allows the physical component inventory and hierarchy to be identified. However, this MIB does not provide persistent component identifiers, which are required for the PTOPO MIB. Therefore, version 2 of the Entity MIB [RFC2737] is required to support that feature. Specifically, the entPhysicalAlias object is utilized as a persistent chassis identifier.
Entity MIB[RFC2037]の最初のバージョンは、物理的構成要素目録と階層構造が特定されるのを許容します。 しかしながら、このMIBは永続的なコンポーネント識別子を提供しません。(識別子がPTOPO MIBに必要です)。 したがって、Entity MIB[RFC2737]のバージョン2が、その特徴をサポートするのに必要です。 明確に、entPhysicalAliasオブジェクトは永続的な筐体識別子として利用されます。
For agents implementing the PTOPO MIB, this new object must be used to represent the chassis identifier. Port identifiers can be based on the entPhysicalAlias object associated with the port, but only if the port is not represented as an interface in the ifXTable.
PTOPO MIBを実装するエージェントに関しては、筐体識別子を表すのにこの新しいオブジェクトを使用しなければなりません。 ポートがインタフェースとしてifXTableに表されない場合にだけ、ポート識別子はポートに関連しているentPhysicalAliasオブジェクトに基づくことができます。
Implementation of the entPhysicalGroup [RFC2737] and the entPhysicalAlias object [RFC2737] are mandatory for SNMP agents which implement the PTOPO MIB. No other objects must be implemented from these MIBs to support the physical topology function.
entPhysicalGroupの実装[RFC2737]とentPhysicalAliasオブジェクト[RFC2737]はSNMPエージェントに義務的です(PTOPO MIBを実装します)。 物理的なトポロジー機能をサポートするためにこれらのMIBsから他のオブジェクトを全く実装してはいけません。
Bierman & Jones Informational [Page 8] RFC 2922 Physical Topology MIB September 2000
物理的な[8ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
4.3. Relationship to Interfaces MIB
4.3. インタフェースMIBとの関係
The PTOPO MIB requires a persistent identifier for each port. The Interfaces MIB [RFC2233] provides a standard mechanism for managing network interfaces. Unfortunately, not all ports which may be represented in the PTOPO MIB are also represented in the Interfaces MIB (e.g., repeater ports).
PTOPO MIBは各ポートのための永続的な識別子を必要とします。 Interfaces MIB[RFC2233]は標準のメカニズムをネットワーク・インターフェースを管理するのに提供します。 残念ながら、また、PTOPO MIBに表されるかもしれないというわけではないすべてのポートがInterfaces MIB(例えば、リピータポート)に表されます。
For agents which implement the PTOPO MIB, for each port also represented in the Interfaces MIB, the agent must use the associated ifAlias value for the port identifier. For each port not represented in the Interfaces MIB, the associated entPhysicalAlias value must be used for the port identifier. Note that the PTOPO MIB requires only minimal support from the Interfaces MIB. Specifically, the ' ifGeneralInformationGroup' level of conformance must be provided for each port also identified in the PTOPO MIB. The agent may choose to support these objects with read-only access, as specified in the conformance section of the Interfaces MIB.
エージェントに関しては、どれが、PTOPO MIBがまた、Interfaces MIBに表された各ポートへのエージェントであると実装するかがポート識別子に関連ifAlias値を使用しなければなりません。 Interfaces MIBに表されなかった各ポートに関しては、ポート識別子に関連entPhysicalAlias値を使用しなければなりません。 PTOPO MIBがInterfaces MIBから最小量のサポートだけを必要とすることに注意してください。 明確に、順応の'ifGeneralInformationGroup'レベルをまた、PTOPO MIBで特定された各ポートに提供しなければなりません。 エージェントは、リード・オンリー・アクセスでこれらのオブジェクトを支えるのを選ぶかもしれません、Interfaces MIBの順応部で指定されるように。
4.4. Relationship to RMON-2 MIB
4.4. RMON-2 MIBとの関係
The RMON-2 MIB [RFC2021] contains address mapping information which can be integrated with physical topology information. The physical ports identified in a physical topology MIB can be related to the MAC and network layer addresses found in the addressMapTable.
RMON-2 MIB[RFC2021]は物理的なトポロジー情報と統合できるアドレスマッピング情報を含んでいます。 物理的なトポロジーMIBで特定された物理的なポートはアドレスがaddressMapTableで見つけたMACとネットワーク層に関連する場合があります。
4.5. Relationship to Bridge MIB
4.5. ブリッジMIBとの関係
The Bridge MIB [RFC1493] contains information which may relate to physical ports represented in the ptopoConnTable. Entries in the dot1dBasePortTable and dot1dStpPortTable can by related to physical ports represented in the PTOPO MIB. Also, bridge port MAC addresses may be used as chassis and port identifiers in some situations.
Bridge MIB[RFC1493]はptopoConnTableに表された物理的なポートに関連するかもしれない情報を含んでいます。 dot1dBasePortTableとdot1dStpPortTable缶におけるエントリーはPTOPO MIBに表された物理的なポートに関連しました。 また、ブリッジポートMACアドレスは筐体とポート識別子としていくつかの状況で使用されるかもしれません。
4.6. Relationship to Repeater MIB
4.6. リピータMIBとの関係
The Repeater MIB [RFC2108] contains information which may relate to physical ports represented in the PTOPO MIB. Entries in the rptrPortTable and rptrMonitorPortTable can by related to physical ports represented in the ptopoConnTable. Entries in the rptrInfoTable and rptrMonTable can be related to repeater backplanes possibly represented in the ptopoConnTable.
Repeater MIB[RFC2108]はPTOPO MIBに表された物理的なポートに関連するかもしれない情報を含んでいます。 rptrPortTableとrptrMonitorPortTable缶におけるエントリーはptopoConnTableに表された物理的なポートに関連しました。 rptrInfoTableとrptrMonTableのエントリーはことによるとptopoConnTableに表されたリピータバックプレーンに関連する場合があります。
Bierman & Jones Informational [Page 9] RFC 2922 Physical Topology MIB September 2000
物理的な[9ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
4.7. MIB Structure
4.7. MIB構造
The PTOPO MIB contains three MIB object groups:
PTOPO MIBは3つのMIBオブジェクトグループを含みます:
- ptopoData
Exposes physical topology data learned from discovery protocols
and/or manual configuration.
- ptopoData Exposesの物理的なトポロジーデータは発見プロトコル、そして/または、手動の構成から学びました。
- ptopoGeneral
Contains general information regarding PTOPO MIB status.
- PTOPO MIB状態に関するptopoGeneral Contains一般情報。
- ptopoConfig
Contains configuration variables for the PTOPO MIB agent
function.
- PTOPO MIBエージェントのためのptopoConfig Contains構成変数は機能します。
4.7.1. ptopoData Group
4.7.1. ptopoDataは分類します。
This group contains a single table to identity physical topology data.
このグループはアイデンティティの物理的なトポロジーデータに単一のテーブルを含みます。
The ptopoConnTable contains information about the connections learned or configured on behalf of the PTOPO MIB SNMP Agent.
ptopoConnTableはPTOPO MIB SNMPエージェントを代表して学習されるか、または構成された接続の情報を含んでいます。
4.7.2. ptopoGeneral Group
4.7.2. ptopoGeneralは分類します。
This group contains some scalar objects to report the status of the PTOPO MIB information currently known to the SNMP Agent. The global last change time, and table add and delete counters allow an NMS to set threshold alarms to trigger PTOPO polling.
このグループはSNMPエージェントにとって、PTOPO MIB情報の状態が現在知られていると報告するいくつかのスカラのオブジェクトを含みます。 グローバルが変化時間続いて、テーブルは、カウンタを加えて、削除します。敷居アラームにPTOPO世論調査の引き金となるようにNMSを設定させてください。
4.7.3. ptopoConfig Group
4.7.3. ptopoConfigは分類します。
This group contains tables to configure the behavior of the physical topology function. The transmission of ptopoLastChange notifications can be configured using the ptopoConfigTrapInterval scalar MIB object.
このグループは物理的なトポロジー機能の振舞いを構成するテーブルを含みます。 ptopoConfigTrapIntervalのスカラのMIBオブジェクトを使用することでptopoLastChange通知の伝達を構成できます。
4.8. Physical Topology MIB Definitions
4.8. 物理的なトポロジーMIB定義
PTOPO-MIB DEFINITIONS ::= BEGIN
PTOPO-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Counter32, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、Integer32、Counter32、mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION、AutonomousType、RowStatus、TimeStamp、TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE、OBJECT-GROUP、NOTIFICATION-GROUP
Bierman & Jones Informational [Page 10] RFC 2922 Physical Topology MIB September 2000
物理的な[10ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
FROM SNMPv2-CONF
TimeFilter
FROM RMON2-MIB
PhysicalIndex
FROM ENTITY-MIB
AddressFamilyNumbers
FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB;
IANAアドレスファミリー数のMIBからの実体-MIB AddressFamilyNumbersからのRMON2-MIB PhysicalIndexからのSNMPv2-CONF TimeFilterから。
ptopoMIB MODULE-IDENTITY
LAST-UPDATED "200009210000Z"
ORGANIZATION "IETF; PTOPOMIB Working Group"
CONTACT-INFO
"PTOPOMIB WG Discussion:
ptopo@3com.com
Subscription:
majordomo@3com.com
msg body: [un]subscribe ptopomib
ptopoMIBモジュールアイデンティティは"200009210000Z"組織"IETF"をアップデートしました。 「PTOPOMIB作業部会」コンタクトインフォメーション、「PTOPOMIB WG議論:」 ptopo@3com.com 購読: majordomo@3com.com msgボディー: [不-、]、ptopomibを申し込んでください。
Andy Bierman
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134
408-527-3711
abierman@cisco.com
西タスマン・Driveサンノゼ、アンディBiermanシスコシステムズInc.170カリフォルニア95134 408-527-3711 abierman@cisco.com
Kendall S. Jones
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
408-495-7356
kejones@nortelnetworks.com"
DESCRIPTION
"The MIB module for physical topology information."
REVISION "200009210000Z"
DESCRIPTION
"Initial Version of the Physical Topology MIB. This version
published as RFC 2922."
::= { mib-2 79 }
「グレート・アメリカパークウェイサンタクララ、ケンドールS.ジョーンズノーテルNetworks4401カリフォルニア95054 408-495-7356 kejones@nortelnetworks.com 」記述、「物理的なトポロジー情報のためのMIBモジュール。」 改正"200009210000Z"記述は「物理的なトポロジーMIBのバージョンに頭文字をつけます」。 「RFC2922として発行されたこのバージョン。」 ::= mib-2 79
ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 }
ptopoMIBObjectsオブジェクト識別子:、:= ptopoMIB1
-- MIB groups
ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }
-- MIBはptopoData OBJECT IDENTIFIERを分類します:、:= ptopoMIBObjects1ptopoGeneralオブジェクト識別子:、:= ptopoMIBObjects2ptopoConfigオブジェクト識別子:、:= ptopoMIBObjects3
-- textual conventions
-- 原文のコンベンション
Bierman & Jones Informational [Page 11] RFC 2922 Physical Topology MIB September 2000
物理的な[11ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
PtopoGenAddr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of an address."
SYNTAX OCTET STRING (SIZE (0..20))
PtopoGenAddr:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「アドレスの値。」 構文八重奏ストリング(サイズ(0 .20))
PtopoChassisIdType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the source of a chassis identifier.
PtopoChassisIdType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このTCは筐体識別子の源について説明します」。
The enumeration 'chasIdEntPhysicalAlias(1)' represents a
chassis identifier based on the value of entPhysicalAlias
for a chassis component (i.e., an entPhysicalClass value of
'chassis(3)').
列挙'chasIdEntPhysicalAlias(1)'は筐体コンポーネント(すなわち、'筐体(3)'のentPhysicalClass値)のためにentPhysicalAliasの値に基づく筐体識別子を表します。
The enumeration 'chasIdIfAlias(2)' represents a chassis
identifier based on the value of ifAlias for an interface
on the containing chassis.
列挙'chasIdIfAlias(2)'は含んでいる筐体にifAliasの値に基づく筐体識別子をインタフェースに表します。
The enumeration 'chasIdPortEntPhysicalAlias(3)' represents
a chassis identifier based on the value of entPhysicalAlias
for a port or backplane component (i.e., entPhysicalClass
value of 'port(10)' or 'backplane(4)'), within the
containing chassis.
列挙'chasIdPortEntPhysicalAlias(3)'はポートかバックプレーンコンポーネント(すなわち、'ポート(10)'か'バックプレーン(4)'のentPhysicalClass値)のためにentPhysicalAliasの値に基づく筐体識別子を表します、含んでいる筐体の中で。
The enumeration 'chasIdMacAddress(4)' represents a chassis
identifier based on the value of a unicast source MAC
address (encoded in network byte order and IEEE 802.3
canonical bit order), of a port on the containing chassis.
列挙'chasIdMacAddress(4)'はユニキャストソースMACアドレス(ネットワークバイトオーダーとIEEE802.3の正準な噛み付いている注文では、コード化される)、含んでいる筐体のポートの値に基づく筐体識別子を表します。
The enumeration 'chasIdPtopoGenAddr(5)' represents a
chassis identifier based on a network address, associated
with a particular chassis. The encoded address is actually
composed of two fields. The first field is a single octet,
representing the IANA AddressFamilyNumbers value for the
specific address type, and the second field is the
PtopoGenAddr address value."
SYNTAX INTEGER {
chasIdEntPhysicalAlias(1),
chasIdIfAlias(2),
chasIdPortEntPhysicalAlias(3),
chasIdMacAddress(4),
chasIdPtopoGenAddr(5)
}
列挙'chasIdPtopoGenAddr(5)'はネットワーク・アドレスに基づいていて、特定の筐体に関連している筐体識別子を表します。 コード化されたアドレスは実際に2つの分野で構成されます。 「特定のアドレスタイプのためにIANA AddressFamilyNumbers値を表して、最初の分野はただ一つの八重奏です、そして、2番目の分野はPtopoGenAddrアドレス値です。」 構文整数chasIdEntPhysicalAlias(1)、chasIdIfAlias(2)、chasIdPortEntPhysicalAlias(3)、chasIdMacAddress(4)、chasIdPtopoGenAddr(5)
PtopoChassisId ::= TEXTUAL-CONVENTION
STATUS current
PtopoChassisId:、:= TEXTUAL-CONVENTION STATUS海流
Bierman & Jones Informational [Page 12] RFC 2922 Physical Topology MIB September 2000
物理的な[12ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
DESCRIPTION
"This TC describes the format of a chassis identifier
string. Objects of this type are always used with an
associated PtopoChassisIdType object, which identifies the
format of the particular PtopoChassisId object instance.
記述、「このTCは筐体識別子ストリングの形式について説明します」。 このタイプのオブジェクトは関連PtopoChassisIdTypeオブジェクトと共にいつも使用されます。(それは、特定のPtopoChassisIdオブジェクトインスタンスの形式を特定します)。
If the associated PtopoChassisIdType object has a value of
'chasIdEntPhysicalAlias(1)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a chassis component (i.e., an entPhysicalClass
value of 'chassis(3)').
関連PtopoChassisIdTypeオブジェクトに'chasIdEntPhysicalAlias(1)'の値があるなら、八重奏ストリングは筐体コンポーネント(すなわち、'筐体(3)'のentPhysicalClass値)のためにentPhysicalAliasオブジェクトの特定のインスタンスを特定します。
If the associated PtopoChassisIdType object has a value of
'chasIdIfAlias(2)', then the octet string identifies a
particular instance of the ifAlias object for an interface
on the containing chassis.
関連PtopoChassisIdTypeオブジェクトに'chasIdIfAlias(2)'の値があるなら、八重奏ストリングは含んでいる筐体でifAliasオブジェクトの特定のインスタンスをインタフェースに特定します。
If the associated PtopoChassisIdType object has a value of
'chasIdPortEntPhysicalAlias(3)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port or backplane component within the
containing chassis.
関連PtopoChassisIdTypeオブジェクトに'chasIdPortEntPhysicalAlias(3)'の値があるなら、八重奏ストリングはポートかバックプレーンコンポーネントのために含んでいる筐体の中でentPhysicalAliasオブジェクトの特定のインスタンスを特定します。
If the associated PtopoChassisIdType object has a value of
'chasIdMacAddress(4)', then this string identifies a
particular unicast source MAC address (encoded in network
byte order and IEEE 802.3 canonical bit order), of a port on
the containing chassis.
関連PtopoChassisIdTypeオブジェクトに'chasIdMacAddress(4)'の値があるなら、このストリングは含んでいる筐体のポートの特定のユニキャストソースMACアドレス(ネットワークバイトオーダーとIEEE802.3の正準な噛み付いている注文では、コード化される)を特定します。
If the associated PtopoChassisIdType object has a value of
'chasIdPtopoGenAddr(5)', then this string identifies a
particular network address, encoded in network byte order,
associated with one or more ports on the containing chassis.
The first octet contains the IANA Address Family Numbers
enumeration value for the specific address type, and octets
2 through N contain the PtopoGenAddr address value in
network byte order."
SYNTAX OCTET STRING (SIZE (1..32))
関連PtopoChassisIdTypeオブジェクトに'chasIdPtopoGenAddr(5)'の値があるなら、このストリングはネットワークバイトオーダーでコード化された含んでいる筐体の1つ以上のポートに関連している特定のネットワーク・アドレスを特定します。 「最初の八重奏は特定のアドレスタイプのためのIANA Address Family民数記列挙価値を含んでいます、そして、八重奏2〜NはネットワークバイトオーダーにおけるPtopoGenAddrアドレス値を含んでいます。」 構文八重奏ストリング(サイズ(1 .32))
PtopoPortIdType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the source of a particular type of port
identifier used in the PTOPO MIB.
PtopoPortIdType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このTCはPTOPO MIBで使用される特定のタイプに関するポート識別子の源について説明します」。
The enumeration 'portIdIfAlias(1)' represents a port
identifier based on the ifAlias MIB object.
列挙'portIdIfAlias(1)'はifAlias MIBオブジェクトに基づくポート識別子を表します。
Bierman & Jones Informational [Page 13] RFC 2922 Physical Topology MIB September 2000
物理的な[13ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
The enumeration 'portIdPortEntPhysicalAlias(2)' represents a
port identifier based on the value of entPhysicalAlias for a
port or backplane component (i.e., entPhysicalClass value of
'port(10)' or 'backplane(4)'), within the containing
chassis.
列挙'portIdPortEntPhysicalAlias(2)'はポートかバックプレーンコンポーネント(すなわち、'ポート(10)'か'バックプレーン(4)'のentPhysicalClass値)のためにentPhysicalAliasの値に基づくポート識別子を表します、含んでいる筐体の中で。
The enumeration 'portIdMacAddr(3)' represents a port
identifier based on a unicast source MAC address, which has
been detected by the agent and associated with a particular
port.
列挙'portIdMacAddr(3)'はエージェントによって検出されて、指定港に関連づけられたユニキャストソースMACアドレスに基づくポート識別子を表します。
The enumeration 'portIdPtopoGenAddr(4)' represents a port
identifier based on a network address, detected by the agent
and associated with a particular port."
SYNTAX INTEGER {
portIdIfAlias(1),
portIdEntPhysicalAlias(2),
portIdMacAddr(3),
portIdPtopoGenAddr(4)
}
「列挙'portIdPtopoGenAddr(4)'はネットワーク・アドレスに基づいていて、エージェントによって検出されて、指定港に関連づけられたポート識別子を表します。」 構文整数portIdIfAlias(1)、portIdEntPhysicalAlias(2)、portIdMacAddr(3)、portIdPtopoGenAddr(4)
PtopoPortId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the format of a port identifier string.
Objects of this type are always used with an associated
PtopoPortIdType object, which identifies the format of the
particular PtopoPortId object instance.
PtopoPortId:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このTCはポート識別子ストリングの形式について説明します」。 このタイプのオブジェクトは関連PtopoPortIdTypeオブジェクトと共にいつも使用されます。(それは、特定のPtopoPortIdオブジェクトインスタンスの形式を特定します)。
If the associated PtopoPortIdType object has a value of
'portIdIfAlias(1)', then the octet string identifies a
particular instance of the ifAlias object.
関連PtopoPortIdTypeオブジェクトに'portIdIfAlias(1)'の値があるなら、八重奏ストリングはifAliasオブジェクトの特定のインスタンスを特定します。
If the associated PtopoPortIdType object has a value of
'portIdEntPhysicalAlias(2)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port component (i.e., entPhysicalClass value of
'port(10)').
関連PtopoPortIdTypeオブジェクトに'portIdEntPhysicalAlias(2)'の値があるなら、八重奏ストリングはポートの部品(すなわち、'ポート(10)'のentPhysicalClass値)のためにentPhysicalAliasオブジェクトの特定のインスタンスを特定します。
If the associated PtopoPortIdType object has a value of
'portIdMacAddr(3)', then this string identifies a particular
unicast source MAC address associated with the port.
関連PtopoPortIdTypeオブジェクトに'portIdMacAddr(3)'の値があるなら、このストリングはポートに関連している特定のユニキャストソースMACアドレスを特定します。
If the associated PtopoPortIdType object has a value of
'portIdPtopoGenAddr(4)', then this string identifies a
network address associated with the port. The first octet
contains the IANA AddressFamilyNumbers enumeration value for
the specific address type, and octets 2 through N contain
関連PtopoPortIdTypeオブジェクトに'portIdPtopoGenAddr(4)'の値があるなら、このストリングはポートに関連しているネットワーク・アドレスを特定します。 最初の八重奏は2〜Nが含む特定のアドレスタイプ、および八重奏のためのIANA AddressFamilyNumbers列挙価値を含んでいます。
Bierman & Jones Informational [Page 14] RFC 2922 Physical Topology MIB September 2000
物理的な[14ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
the PtopoGenAddr address value in network byte order."
SYNTAX OCTET STRING (SIZE (1..32))
「PtopoGenAddrはネットワークバイトオーダーにおける値を扱います。」 構文八重奏ストリング(サイズ(1 .32))
PtopoAddrSeenState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes the state of address detection for a
particular type of port identifier used in the PTOPO MIB.
PtopoAddrSeenState:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このTCはPTOPO MIBで使用される特定のタイプに関するポート識別子のためのアドレス検出の状態について説明します」。
The enumeration 'notUsed(1)' represents an entry for which
the particular MIB object is not applicable to the remote
connection endpoint,
列挙'notUsed(1)'は特定のMIBオブジェクトが遠く離れた接続終点に適切でないエントリーを表します。
The enumeration 'unknown(2)' represents an entry for which
the particular address collection state is not known.
列挙'未知(2)'は特定のアドレス収集状態が知られていないエントリーを表します。
The enumeration 'oneAddr(3)' represents an entry for which
exactly one source address (of the type indicated by the
particular MIB object), has been detected.
列挙'oneAddr(3)'は、どのまさに1つのソースのアドレス(特定のMIBオブジェクトによって示されたタイプの)のためにエントリーを表すか、そして、検出されました。
The enumeration 'multiAddr(4)' represents an entry for
which more than one source address (of the type indicated by
the particular MIB object), has been detected.
列挙'multiAddr(4)'は、どの1つ以上のソースアドレス(特定のMIBオブジェクトによって示されたタイプの)のためにエントリーを表すか、そして、検出されました。
An agent is expected to set the initial state of the
PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'.
エージェントが'notUsed(1)'か'未知(2)'にPtopoAddrSeenStateの初期状態を設定すると予想されます。
Note that the PTOPO MIB does not restrict or specify the
means in which the PtopoAddrSeenState is known to an agent.
In particular, an agent may detect this information through
configuration data, or some means other than directly
monitoring all port traffic."
SYNTAX INTEGER {
notUsed(1),
unknown(2),
oneAddr(3),
multiAddr(4)
}
PTOPO MIBがPtopoAddrSeenStateがエージェントにとって知られている手段を制限もしませんし、指定もしないことに注意してください。 「エージェントは、特に、コンフィギュレーション・データを通してこの情報を検出するか、または直接すべてのポートトラフィックをモニターするのを除いて、いくつかの手段を検出するかもしれません。」 構文整数notUsed(1)、未知(2)、oneAddr(3)、multiAddr(4)
-- *********************************************************** -- -- P T O P O D A T A G R O U P -- -- ***********************************************************
-- *********************************************************** -- -- P T O P O D A T A G R O U P -- -- ***********************************************************
-- Connection Table
-- 接続テーブル
Bierman & Jones Informational [Page 15] RFC 2922 Physical Topology MIB September 2000
物理的な[15ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
ptopoConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF PtopoConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one or more rows per physical network
connection known to this agent. The agent may wish to
ensure that only one ptopoConnEntry is present for each
local port, or it may choose to maintain multiple
ptopoConnEntries for the same local port.
「このテーブルはこのエージェントにとって知られている物理ネットワーク接続あたり1つ以上の行に含む」ptopoConnTable OBJECT-TYPE SYNTAX SEQUENCE OF PtopoConnEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 エージェントが、1ptopoConnEntryだけがそれぞれの地方のポートに存在しているのを保証したがっているかもしれませんか、またはそれは、同じ地方のポートに複数のptopoConnEntriesを維持するのを選ぶかもしれません。
Entries based on lower numbered identifier types are
preferred over higher numbered identifier types, i.e., lower
values of the ptopoConnRemoteChassisType and
ptopoConnRemotePortType objects."
::= { ptopoData 1 }
「低い番号付の識別子タイプに基づくエントリーはすなわち、より高い番号付の識別子タイプ、ptopoConnRemoteChassisTypeとptopoConnRemotePortTypeオブジェクトの下側の値より好まれます。」 ::= ptopoData1
ptopoConnEntry OBJECT-TYPE
SYNTAX PtopoConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular physical network connection.
Entries may be created and deleted in this table, either
manually or by the agent, if a physical topology discovery
process is active."
INDEX {
ptopoConnTimeMark,
ptopoConnLocalChassis,
ptopoConnLocalPort,
ptopoConnIndex
}
::= { ptopoConnTable 1 }
ptopoConnEntry OBJECT-TYPE SYNTAX PtopoConnEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の物理ネットワーク接続に関する情報。」 「エントリーは、このテーブル、手動またはエージェントによって作成されて、削除されるかもしれません、物理的なトポロジー発見プロセスがアクティブであるなら。」 ptopoConnTimeMark、ptopoConnLocalChassis、ptopoConnLocalPort、ptopoConnIndexに索引をつけてください:、:= ptopoConnTable1
PtopoConnEntry ::= SEQUENCE {
ptopoConnTimeMark TimeFilter,
ptopoConnLocalChassis PhysicalIndex,
ptopoConnLocalPort PhysicalIndex,
ptopoConnIndex Integer32,
ptopoConnRemoteChassisType PtopoChassisIdType,
ptopoConnRemoteChassis PtopoChassisId,
ptopoConnRemotePortType PtopoPortIdType,
ptopoConnRemotePort PtopoPortId,
ptopoConnDiscAlgorithm AutonomousType,
ptopoConnAgentNetAddrType AddressFamilyNumbers,
ptopoConnAgentNetAddr PtopoGenAddr,
ptopoConnMultiMacSASeen PtopoAddrSeenState,
ptopoConnMultiNetSASeen PtopoAddrSeenState,
PtopoConnEntry:、:= 系列、ptopoConnTimeMark TimeFilter、ptopoConnLocalChassis PhysicalIndex、ptopoConnLocalPort PhysicalIndex、ptopoConnIndex Integer32、ptopoConnRemoteChassisType PtopoChassisIdType、ptopoConnRemoteChassis PtopoChassisId、ptopoConnRemotePortType PtopoPortIdType、ptopoConnRemotePort PtopoPortId、ptopoConnDiscAlgorithm AutonomousType、ptopoConnAgentNetAddrType AddressFamilyNumbers、ptopoConnAgentNetAddr PtopoGenAddr、ptopoConnMultiMacSASeen PtopoAddrSeenState、ptopoConnMultiNetSASeen PtopoAddrSeenState
Bierman & Jones Informational [Page 16] RFC 2922 Physical Topology MIB September 2000
物理的な[16ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
ptopoConnIsStatic TruthValue,
ptopoConnLastVerifyTime TimeStamp,
ptopoConnRowStatus RowStatus
}
ptopoConnIsStatic TruthValue、ptopoConnLastVerifyTimeタイムスタンプ、ptopoConnRowStatus RowStatus
ptopoConnTimeMark OBJECT-TYPE
SYNTAX TimeFilter
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A TimeFilter for this entry. See the TimeFilter textual
convention in RFC 2021 to see how this works."
::= { ptopoConnEntry 1 }
ptopoConnTimeMark OBJECT-TYPE SYNTAX TimeFilterのマックス-ACCESSのアクセスしやすくないSTATUSの現在の記述「このエントリーへのA TimeFilter。」 「これがどう働いているかを見るためにRFC2021のTimeFilterの原文のコンベンションを見てください。」 ::= ptopoConnEntry1
ptopoConnLocalChassis OBJECT-TYPE
SYNTAX PhysicalIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entPhysicalIndex value used to identify the chassis
component associated with the local connection endpoint."
::= { ptopoConnEntry 2 }
ptopoConnLocalChassis OBJECT-TYPE SYNTAX PhysicalIndexのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「以前はよく市内接続終点に関連している筐体コンポーネントを特定entPhysicalIndexが評価するしていました」。 ::= ptopoConnEntry2
ptopoConnLocalPort OBJECT-TYPE
SYNTAX PhysicalIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entPhysicalIndex value used to identify the port
component associated with the local connection endpoint."
::= { ptopoConnEntry 3 }
ptopoConnLocalPort OBJECT-TYPE SYNTAX PhysicalIndexのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「以前はよく市内接続終点に関連しているポートの部品を特定entPhysicalIndexが評価するしていました」。 ::= ptopoConnEntry3
ptopoConnIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents an arbitrary local integer value
used by this agent to identify a particular connection
instance, unique only for the indicated local connection
endpoint.
「このオブジェクトは値が示された市内接続終点だけに、ユニークな特定の接続インスタンスを特定するのにこのエージェントで使用した任意の地方の整数に表す」ptopoConnIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
A particular ptopoConnIndex value may be reused in the event
an entry is aged out and later re-learned with the same (or
different) remote chassis and port identifiers.
特定のptopoConnIndex値は、エントリーが熟成するイベントで再利用されて、後で同じで(異なる)のリモート筐体とポート識別子で再学習されるかもしれません。
An agent is encouraged to assign monotonically increasing
index values to new entries, starting with one, after each
それぞれ後に1つから始めて、エージェントが増加するインデックス値を新しいエントリーに単調に割り当てるよう奨励されます。
Bierman & Jones Informational [Page 17] RFC 2922 Physical Topology MIB September 2000
物理的な[17ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
reboot. It is considered unlikely that the ptopoConnIndex
will wrap between reboots."
::= { ptopoConnEntry 4 }
リブートしてください。 「ptopoConnIndexがリブートの間で包装するのはありそうもないと考えられます。」 ::= ptopoConnEntry4
ptopoConnRemoteChassisType OBJECT-TYPE
SYNTAX PtopoChassisIdType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of encoding used to identify the chassis
associated with the remote connection endpoint.
ptopoConnRemoteChassisType OBJECT-TYPE SYNTAX PtopoChassisIdTypeマックス-ACCESSは「コード化のタイプは遠く離れた接続終点に関連している筐体を特定するのに使用した」STATUSの現在の記述を読書して作成します。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 5 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 ::= ptopoConnEntry5
ptopoConnRemoteChassis OBJECT-TYPE
SYNTAX PtopoChassisId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The string value used to identify the chassis component
associated with the remote connection endpoint.
ptopoConnRemoteChassis OBJECT-TYPE SYNTAX PtopoChassisIdマックス-ACCESSは「ストリング値は遠く離れた接続終点に関連している筐体コンポーネントを特定するのに使用した」STATUSの現在の記述を読書して作成します。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 6 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 ::= ptopoConnEntry6
ptopoConnRemotePortType OBJECT-TYPE
SYNTAX PtopoPortIdType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of port identifier encoding used in the associated
'ptopoConnRemotePort' object.
ptopoConnRemotePortType OBJECT-TYPE SYNTAX PtopoPortIdTypeマックス-ACCESSは「ポート識別子コード化のタイプは関連'ptopoConnRemotePort'オブジェクトで使用した」STATUSの現在の記述を読書して作成します。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 7 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 ::= ptopoConnEntry7
ptopoConnRemotePort OBJECT-TYPE
SYNTAX PtopoPortId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The string value used to identify the port component
associated with the remote connection endpoint.
ptopoConnRemotePort OBJECT-TYPE SYNTAX PtopoPortIdマックス-ACCESSは「ストリング値は遠く離れた接続終点に関連しているポートの部品を特定するのに使用した」STATUSの現在の記述を読書して作成します。
Bierman & Jones Informational [Page 18] RFC 2922 Physical Topology MIB September 2000
物理的な[18ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 8 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 ::= ptopoConnEntry8
ptopoConnDiscAlgorithm OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the algorithm used to discover the
information contained in this conceptual row.
「アルゴリズムのしるしはこの概念的な行に含まれた情報を発見するのに使用した」ptopoConnDiscAlgorithm OBJECT-TYPE SYNTAX AutonomousTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
A value of ptopoDiscoveryLocal indicates this entry was
configured by the local agent, without use of a discovery
protocol.
ptopoDiscoveryLocalの値は、このエントリーが発見プロトコルの使用なしで地元のエージェントによって構成されたのを示します。
A value of { 0 0 } indicates this entry was created manually
by an NMS via the associated RowStatus object. "
::= { ptopoConnEntry 9 }
0 0の値は、このエントリーが関連RowStatusオブジェクトを通してNMSによって手動で作成されたのを示します。 " ::= ptopoConnEntry9
ptopoConnAgentNetAddrType OBJECT-TYPE
SYNTAX AddressFamilyNumbers
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This network address type of the associated
ptopoConnNetAddr object, unless that object contains a zero
length string. In such a case, an NMS application should
ignore any returned value for this object.
ptopoConnAgentNetAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbersマックス-ACCESSは「そのオブジェクトがゼロ長ストリングを含んでいない場合、このネットワークは関連ptopoConnNetAddrオブジェクトのタイプに演説する」STATUSの現在の記述を読書して作成します。 このような場合には、NMSアプリケーションはこのオブジェクトのためにどんな戻り値も無視するべきです。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
::= { ptopoConnEntry 10 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 ::= ptopoConnEntry10
ptopoConnAgentNetAddr OBJECT-TYPE
SYNTAX PtopoGenAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies a network address which may be used
to reach an SNMP agent entity containing information for the
chassis and port components represented by the associated
'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects.
If no such address is known, then this object shall contain
an empty string.
ptopoConnAgentNetAddr OBJECT-TYPE SYNTAX PtopoGenAddrマックス-ACCESSはSTATUSの現在の記述「このオブジェクトは筐体のための情報を含むSNMPエージェント実体に達して、関連によって表されたコンポーネントを移植するのに使用されるかもしれないネットワーク・アドレスを特定する'ptopoConnRemoteChassisと''ptopoConnRemotePort'オブジェクト」を読書して作成します。 何かそのようなアドレスが知られていないなら、このオブジェクトは空のストリングを含むものとします。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」
Bierman & Jones Informational [Page 19] RFC 2922 Physical Topology MIB September 2000
物理的な[19ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
::= { ptopoConnEntry 11 }
::= ptopoConnEntry11
ptopoConnMultiMacSASeen OBJECT-TYPE
SYNTAX PtopoAddrSeenState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if multiple unicast source MAC
addresses have been detected by the agent from the remote
connection endpoint, since the creation of this entry.
ptopoConnMultiMacSASeen OBJECT-TYPE SYNTAX PtopoAddrSeenStateのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このエントリーの作成以来複数のユニキャストソースMACアドレスがエージェントによって遠く離れた接続終点から検出されているかどうかを示これが反対するします」。
If this entry has an associated ptopoConnRemoteChassisType
and/or ptopoConnRemotePortType value other than
'portIdMacAddr(3)', then the value 'notUsed(1)' is returned.
このエントリーに'portIdMacAddr(3)'を除いた関連ptopoConnRemoteChassisType、そして/または、ptopoConnRemotePortType値があるなら、値の'notUsed(1)'を返します。
Otherwise, one of the following conditions must be true:
さもなければ、以下の条件の1つは本当であるに違いありません:
If the agent has not yet detected any unicast source MAC
addresses from the remote port, then the value 'unknown(2)'
is returned.
エージェントがまだソースMACが遠く離れたポートから扱うどんなユニキャストも検出していないなら、値の'未知(2)'を返します。
If the agent has detected exactly one unicast source MAC
address from the remote port, then the value 'oneAddr(3)' is
returned.
エージェントが遠く離れたポートからのまさに1つのユニキャストソースMACアドレスを検出したなら、値の'oneAddr(3)'を返します。
If the agent has detected more than one unicast source MAC
address from the remote port, then the value 'multiAddr(4)'
is returned."
::= { ptopoConnEntry 12 }
「エージェントが遠く離れたポートからの1つ以上のユニキャストソースMACアドレスを検出したなら、値の'multiAddr(4)'を返します。」 ::= ptopoConnEntry12
ptopoConnMultiNetSASeen OBJECT-TYPE
SYNTAX PtopoAddrSeenState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if multiple network layer source
addresses have been detected by the agent from the remote
connection endpoint, since the creation of this entry.
ptopoConnMultiNetSASeen OBJECT-TYPE SYNTAX PtopoAddrSeenStateのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このエントリーの作成以来複数のネットワーク層ソースアドレスがエージェントによって遠く離れた接続終点から検出されたかどうかを示これが反対するします」。
If this entry has an associated ptopoConnRemoteChassisType
or ptopoConnRemotePortType value other than
'portIdGenAddr(4)' then the value 'notUsed(1)' is returned.
このエントリーに'portIdGenAddr(4)'を除いた関連ptopoConnRemoteChassisTypeかptopoConnRemotePortType値があるなら、値の'notUsed(1)'を返します。
Otherwise, one of the following conditions must be true:
さもなければ、以下の条件の1つは本当であるに違いありません:
If the agent has not yet detected any network source
addresses of the appropriate type from the remote port, then
the value 'unknown(2)' is returned.
エージェントが遠く離れたポートから適切なタイプの少しのネットワークソースアドレスもまだ検出していないなら、値の'未知(2)'を返します。
Bierman & Jones Informational [Page 20] RFC 2922 Physical Topology MIB September 2000
物理的な[20ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
If the agent has detected exactly one network source address
of the appropriate type from the remote port, then the value
'oneAddr(3)' is returned.
エージェントが遠く離れたポートからまさに適切なタイプの1つのネットワークソースアドレスを検出したなら、値の'oneAddr(3)'を返します。
If the agent has detected more than one network source
address (of the same appropriate type) from the remote port,
this the value 'multiAddr(4)' is returned."
::= { ptopoConnEntry 13 }
「エージェントが遠く離れたポートから1つ以上のネットワークソースアドレスを検出したなら(同じ適切なタイプについて)、この値の'multiAddr(4)'を返します。」 ::= ptopoConnEntry13
ptopoConnIsStatic OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies static ptopoConnEntries. If this
object has the value 'true(1)', then this entry is not
subject to any age-out mechanisms implemented by the agent.
ptopoConnIsStatic OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトは静的なptopoConnEntriesを特定します」。 (1) 'このオブジェクトに値が'本当にあるなら、このエントリーはエージェントによって実装されたどんな外の時代メカニズムも受けることがありません。
If this object has the value 'false(2)', then this entry is
subject to all age-out mechanisms implemented by the agent.
(2) 'このオブジェクトに値が'虚偽であるなら、このエントリーはエージェントによって実装されたすべての外の時代メカニズムを受けることがあります。
This object may not be modified if the associated
ptopoConnRowStatus object has a value of active(1)."
DEFVAL { false }
::= { ptopoConnEntry 14 }
「関連ptopoConnRowStatusオブジェクトにアクティブな(1)の値があるなら、このオブジェクトは変更されないかもしれません。」 DEFVAL偽:、:= ptopoConnEntry14
ptopoConnLastVerifyTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the associated value of ptopoConnIsStatic is equal to
'false(2)', then this object contains the value of sysUpTime
at the time the conceptual row was last verified by the
agent, e.g., via reception of a topology protocol message,
pertaining to the associated remote chassis and port.
ptopoConnLastVerifyTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「ptopoConnIsStaticの関連値が'誤った(2)'と等しいなら、概念的な行が最後にエージェントによって確かめられたとき、このオブジェクトはsysUpTimeの値を含んでいます、例えば、トポロジープロトコルメッセージのレセプションを通して、関連リモート筐体とポートに関して」。
If the associated value of ptopoConnIsStatic is equal to
'true(1)', then this object shall contain the value of
sysUpTime at the time this entry was last activated (i.e.,
ptopoConnRowStatus set to 'active(1)')."
::= { ptopoConnEntry 15 }
「ptopoConnIsStaticの関連値が'本当の(1)'と等しいなら、このエントリーが最後に起動されたとき(すなわち、ptopoConnRowStatusは'アクティブな(1)'にセットしました)、このオブジェクトはsysUpTimeの値を含むものとします。」 ::= ptopoConnEntry15
ptopoConnRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
ptopoConnRowStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。
Bierman & Jones Informational [Page 21] RFC 2922 Physical Topology MIB September 2000
物理的な[21ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
"The status of this conceptual row."
::= { ptopoConnEntry 16 }
「この概念的な行の状態。」 ::= ptopoConnEntry16
-- *********************************************************** -- -- P T O P O G E N E R A L G R O U P -- -- ***********************************************************
-- *********************************************************** -- -- P T O P O G E N E R A L G R O U P -- -- ***********************************************************
-- last change time stamp for the whole MIB
-- 最後に、全体のMIBのためにタイムスタンプを変えてください。
ptopoLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in the ptopoConnTable.
「作成されて、変更されているか、またはptopoConnTableで削除されて、時にa概念的なsysUpTimeの値はこぐ」ptopoLastChangeTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
An NMS can use this object to reduce polling of the
ptopoData group objects."
::= { ptopoGeneral 1 }
「NMSはptopoData群対象の世論調査を抑えるのにこのオブジェクトを使用できます。」 ::= ptopoGeneral1
ptopoConnTabInserts OBJECT-TYPE
SYNTAX Counter32
UNITS "table entries"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry has been inserted into the
ptopoConnTable."
::= { ptopoGeneral 2 }
エントリー」 マックス-ACCESS読書だけSTATUS現在の記述を見送ってください。ptopoConnTabInserts OBJECT-TYPE SYNTAX Counter32 UNITS、「「エントリーをptopoConnTableに挿入してあるという回の数。」 ::= ptopoGeneral2
ptopoConnTabDeletes OBJECT-TYPE
SYNTAX Counter32
UNITS "table entries"
MAX-ACCESS read-only
STATUS current
ptopoConnTabDeletes OBJECT-TYPE SYNTAX Counter32 UNITS「テーブル項目」マックス-ACCESS書き込み禁止STATUS海流
DESCRIPTION
"The number of times an entry has been deleted from the
ptopoConnTable."
::= { ptopoGeneral 3 }
記述、「エントリーがptopoConnTableから削除されたという回の数。」 ::= ptopoGeneral3
ptopoConnTabDrops OBJECT-TYPE
SYNTAX Counter32
UNITS "table entries"
MAX-ACCESS read-only
ptopoConnTabDrops OBJECT-TYPE SYNTAX Counter32 UNITS「テーブル項目」マックス-ACCESS書き込み禁止
Bierman & Jones Informational [Page 22] RFC 2922 Physical Topology MIB September 2000
物理的な[22ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
STATUS current
DESCRIPTION
"The number of times an entry would have been added to the
ptopoConnTable, (e.g., via information learned from a
topology protocol), but was not because of insufficient
resources."
::= { ptopoGeneral 4 }
STATUSの現在の記述、「エントリーがそうする回の数がptopoConnTableに加えられる、(例えば、トポロジープロトコルから学習された情報を通した)、不十分なリソースのためになかった、」 ::= ptopoGeneral4
ptopoConnTabAgeouts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an entry has been deleted from the
ptopoConnTable because the information timeliness interval
for that entry has expired."
::= { ptopoGeneral 5 }
ptopoConnTabAgeouts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「そのエントリーへの情報タイムリー間隔が期限が切れたのでエントリーがptopoConnTableから削除されたという回の数。」 ::= ptopoGeneral5
-- *********************************************************** -- -- P T O P O C O N F I G G R O U P -- -- ***********************************************************
-- *********************************************************** -- -- C
ptopoConfigTrapInterval OBJECT-TYPE
SYNTAX Integer32 (0 | 5..3600)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the transmission of PTOPO
notifications.
ptopoConfigTrapInterval OBJECT-TYPE SYNTAX Integer32、(0|5 .3600)UNITS「秒」マックス-ACCESSは「このオブジェクトはPTOPO通知の伝達を制御すること」をSTATUSの現在の記述に読書して書きます。
If this object has a value of zero, then no
ptopoConfigChange notifications will be transmitted by the
agent.
このオブジェクトにゼロの値があると、ptopoConfigChange通知は全くエージェントによって伝えられないでしょう。
If this object has a non-zero value, then the agent must not
generate more than one ptopoConfigChange trap-event in the
indicated period, where a 'trap-event' is the transmission
of a single notification PDU type to a list of notification
destinations. If additional configuration changes occur
within the indicated throttling period, then these trap-
events must be suppressed by the agent. An NMS should
periodically check the value of ptopoLastChangeTime to
detect any missed ptopoConfigChange trap-events, e.g. due to
throttling or transmission loss.
このオブジェクトに非ゼロ値があるなら、エージェントは示された時代に1つ以上のptopoConfigChange罠イベントを生成してはいけません、'罠イベント'が通知の目的地のリストへの単独の通知PDUタイプのトランスミッションであるところで。 追加構成変更が示された阻止の期間中に起こるなら、エージェントはこれらの罠イベントを抑圧しなければなりません。 NMSはどんな逃されたptopoConfigChange罠イベントも検出するために定期的にptopoLastChangeTimeの値をチェックするはずです、例えば、阻止か動作減衰量のため。
Bierman & Jones Informational [Page 23] RFC 2922 Physical Topology MIB September 2000
物理的な[23ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
If notification transmission is enabled, the suggested
default throttling period is 60 seconds, but transmission
should be disabled by default.
通知送信が可能にされるなら、期間を阻止する提案されたデフォルトは60秒ですが、トランスミッションはデフォルトで無効にされるべきです。
If the agent is capable of storing non-volatile
configuration, then the value of this object must be
restored after a re-initialization of the management
system."
DEFVAL { 0 }
::= { ptopoConfig 1 }
「エージェントが非揮発性の構成を保存できるなら、マネージメントシステムの再初期化の後にこのオブジェクトの値を回復しなければなりません。」 DEFVAL0:、:= ptopoConfig1
ptopoConfigMaxHoldTime OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the desired time interval for which
an agent will maintain dynamic ptopoConnEntries.
ptopoConfigMaxHoldTime OBJECT-TYPE SYNTAX Integer32(1 .2147483647)UNITS「秒」マックス-ACCESSは「このオブジェクトはエージェントがダイナミックなptopoConnEntriesを維持する必要な時間間隔を指定すること」をSTATUSの現在の記述に読書して書きます。
After the specified number of seconds since the last time an
entry was verified, in the absence of new verification
(e.g., receipt of a topology protocol message), the agent
shall remove the entry. Note that entries may not always be
removed immediately, but may possibly be removed at periodic
garbage collection intervals.
This object only affects dynamic ptopoConnEntries, i.e. for
which ptopoConnIsStatic equals 'false(2)'. Static entries
are not aged out.
エントリーが新しい検証がないとき最後の時間確かめられて以来の秒(例えば、トポロジープロトコルメッセージの領収書)の指定された数の後に、エージェントはエントリーを取り除くものとします。 エントリーをすぐにいつも取り除くというわけではありませんが、ことによると周期的なガーベージコレクション間隔で、取り除くかもしれないことに注意してください。 すなわち、どのptopoConnIsStaticが'誤った(2)'と等しいように、このオブジェクトはダイナミックなptopoConnEntriesに影響するだけであるか。 静的なエントリーは外で熟成しません。
Note that dynamic ptopoConnEntries may also be removed by
the agent due to the expired timeliness of learned topology
information (e.g., timeliness interval for a remote port
expires). The actual age-out interval for a given entry is
defined by the following formula:
また、ダイナミックなptopoConnEntriesが学術的トポロジー情報の満期のタイムリーさのためエージェントが取り外されるかもしれないことに注意してください(例えば遠く離れたポートへのタイムリー間隔は期限が切れます)。 与えられたエントリーへの実際の外の時代間隔は以下の公式によって定義されます:
age-out-time =
min(ptopoConfigMaxHoldTime, <entry-specific hold-time>)
アウト時間時代=分(ptopoConfigMaxHoldTime、<エントリー特有の保持時間>)
where <entry-specific hold-time> is determined by the
discovery algorithm, and may be different for each entry."
DEFVAL { 300 }
::= { ptopoConfig 2 }
「<エントリー特有の保持時間>が発見アルゴリズムで決定して、各エントリーにおいて、異なるかもしれないところ。」 DEFVAL300:、:= ptopoConfig2
-- PTOPO MIB Notification Definitions
ptopoMIBNotifications OBJECT IDENTIFIER ::= { ptopoMIB 2 }
ptopoMIBTrapPrefix OBJECT IDENTIFIER ::=
-- PTOPO MIB通知定義ptopoMIBNotificationsオブジェクト識別子:、:= ptopoMIB2ptopoMIBTrapPrefixオブジェクト識別子:、:=
Bierman & Jones Informational [Page 24] RFC 2922 Physical Topology MIB September 2000
物理的な[24ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
{ ptopoMIBNotifications 0 }
ptopoMIBNotifications0
ptopoConfigChange NOTIFICATION-TYPE
OBJECTS {
ptopoConnTabInserts,
ptopoConnTabDeletes,
ptopoConnTabDrops,
ptopoConnTabAgeouts
}
STATUS current
DESCRIPTION
"A ptopoConfigChange notification is sent when the value of
ptopoLastChangeTime changes. It can be utilized by an NMS to
trigger physical topology table maintenance polls.
ptopoConfigChange NOTIFICATION-TYPE OBJECTS、ptopoConnTabInserts、ptopoConnTabDeletes、ptopoConnTabDrops、ptopoConnTabAgeouts、「ptopoLastChangeTimeの値が変化するときptopoConfigChange通知を送る」STATUSの現在の記述。 NMSは、物理的なトポロジーテーブルメインテナンス投票の引き金となるのにそれを利用できます。
Note that transmission of ptopoConfigChange notifications
are throttled by the agent, as specified by the
'ptopoConfigTrapInterval' object."
::= { ptopoMIBTrapPrefix 1 }
「ptopoConfigChange通知の伝達がある注意がエージェントによって阻止されて、'ptopoConfigTrapInterval'によって指定されるように反対してください。」 ::= ptopoMIBTrapPrefix1
-- PTOPO Registration Points
ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 }
-- PTOPO登録はptopoRegistrationPointsオブジェクト識別子を指します:、:= ptopoMIB3
-- values used with ptopoConnDiscAlgorithm object
ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::=
{ ptopoRegistrationPoints 1 }
-- ptopoConnDiscAlgorithmオブジェクトptopoDiscoveryMechanisms OBJECT IDENTIFIERと共に使用される値:、:= ptopoRegistrationPoints1
ptopoDiscoveryLocal OBJECT IDENTIFIER ::=
{ ptopoDiscoveryMechanisms 1 }
ptopoDiscoveryLocalオブジェクト識別子:、:= ptopoDiscoveryMechanisms1
-- conformance information
ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }
-- 順応情報ptopoConformance OBJECT IDENTIFIER:、:= ptopoMIB4
ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 }
ptopoCompliancesオブジェクト識別子:、:= ptopoConformance1ptopoGroupsオブジェクト識別子:、:= ptopoConformance2
-- compliance statements
ptopoCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
the PTOPO MIB."
MODULE -- this module
MANDATORY-GROUPS {
ptopoDataGroup,
-- 承諾声明ptopoCompliance MODULE-COMPLIANCE STATUS現在の記述、「PTOPO MIBを実装するSNMP実体のための承諾声明。」 MODULE--、このモジュールMANDATORY-GROUPS、ptopoDataGroup
Bierman & Jones Informational [Page 25] RFC 2922 Physical Topology MIB September 2000
物理的な[25ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
ptopoGeneralGroup,
ptopoConfigGroup,
ptopoNotificationsGroup
}
::= { ptopoCompliances 1 }
ptopoGeneralGroup、ptopoConfigGroup、ptopoNotificationsGroup ::= ptopoCompliances1
-- MIB groupings
ptopoDataGroup OBJECT-GROUP
OBJECTS {
ptopoConnRemoteChassisType,
ptopoConnRemoteChassis,
ptopoConnRemotePortType,
ptopoConnRemotePort,
ptopoConnDiscAlgorithm,
ptopoConnAgentNetAddrType,
ptopoConnAgentNetAddr,
ptopoConnMultiMacSASeen,
ptopoConnMultiNetSASeen,
ptopoConnIsStatic,
ptopoConnLastVerifyTime,
ptopoConnRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects which are used to represent
physical topology information for which a single agent
provides management information.
-- MIB組分けptopoDataGroup OBJECT-GROUP OBJECTS、ptopoConnRemoteChassisType、ptopoConnRemoteChassis、ptopoConnRemotePortType、ptopoConnRemotePort、ptopoConnDiscAlgorithm、ptopoConnAgentNetAddrType、ptopoConnAgentNetAddr、ptopoConnMultiMacSASeen、ptopoConnMultiNetSASeen、ptopoConnIsStatic、ptopoConnLastVerifyTime、ptopoConnRowStatus、STATUSの現在の記述、「独身のエージェントが経営情報を提供する物理的なトポロジー情報を表すのに使用されるオブジェクトの収集。」
This group is mandatory for all implementations of the PTOPO
MIB."
::= { ptopoGroups 1 }
「このグループはPTOPO MIBのすべての実装に義務的です。」 ::= ptopoGroups1
ptopoGeneralGroup OBJECT-GROUP
OBJECTS {
ptopoLastChangeTime,
ptopoConnTabInserts,
ptopoConnTabDeletes,
ptopoConnTabDrops,
ptopoConnTabAgeouts
}
STATUS current
DESCRIPTION
"The collection of objects which are used to report the
general status of the PTOPO MIB implementation.
ptopoGeneralGroup OBJECT-GROUP OBJECTS、ptopoLastChangeTime、ptopoConnTabInserts、ptopoConnTabDeletes、ptopoConnTabDrops、ptopoConnTabAgeouts、STATUSの現在の記述、「PTOPO MIB実装の一般的な状態を報告するのに使用されるオブジェクトの収集。」
This group is mandatory for all agents which implement the
PTOPO MIB."
::= { ptopoGroups 2 }
「このグループはすべてのエージェントに義務的です(PTOPO MIBを実装します)。」 ::= ptopoGroups2
Bierman & Jones Informational [Page 26] RFC 2922 Physical Topology MIB September 2000
物理的な[26ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
ptopoConfigGroup OBJECT-GROUP
OBJECTS {
ptopoConfigTrapInterval,
ptopoConfigMaxHoldTime
}
STATUS current
DESCRIPTION
"The collection of objects which are used to configure the
PTOPO MIB implementation behavior.
ptopoConfigGroup OBJECT-GROUP OBJECTS、ptopoConfigTrapInterval、ptopoConfigMaxHoldTime、STATUSの現在の記述、「PTOPO MIB実装の振舞いを構成するのに使用されるオブジェクトの収集。」
This group is mandatory for agents which implement the PTOPO
MIB."
::= { ptopoGroups 3 }
「このグループはエージェントに義務的です(PTOPO MIBを実装します)。」 ::= ptopoGroups3
ptopoNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
ptopoConfigChange
}
STATUS current
DESCRIPTION
"The collection of notifications used to indicate PTOPO MIB
data consistency and general status information.
ptopoNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS ptopoConfigChange、「通知の収集はPTOPO MIBデータの一貫性と一般的な状態情報を示すのに使用した」STATUSの現在の記述。
This group is mandatory for agents which implement the PTOPO
MIB."
::= { ptopoGroups 4 }
「このグループはエージェントに義務的です(PTOPO MIBを実装します)。」 ::= ptopoGroups4
END
終わり
5. Intellectual Property
5. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice
IETFは練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。
Bierman & Jones Informational [Page 27] RFC 2922 Physical Topology MIB September 2000
物理的な[27ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
this standard. Please address the information to the IETF Executive Director.
この規格。 IETF専務に情報を扱ってください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
6. Acknowledgements
6. 承認
The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB Working Group.
PTOPOディスカバリープロトコルはIETF PTOPOMIB作業部会の製品です。
7. References
7. 参照
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K.
McCloghrie, "Definitions of Managed Objects for Bridges",
RFC 1493, July 1993.
[RFC1493] デッカーとE.とLangilleとP.とRijsinghaniとA.とK.McCloghrie、「ブリッジのための管理オブジェクトの定義」、RFC1493、1993年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、1996年1月。」
[RFC1902] 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.
[RFC1902]ケースとJ.とMcCloghrieとK.とローズ、M.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」RFC1902(1996年1月)。
[RFC1903] 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.
[RFC1903]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」、RFC1903、1996年1月。
Bierman & Jones Informational [Page 28] RFC 2922 Physical Topology MIB September 2000
物理的な[28ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
[RFC1904] 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.
[RFC1904]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための順応Statements」、RFC1904、1996年1月。
[RFC1905] 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.
[RFC1905]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
RFC 2021, January 1997.
S.、「リモートネットワーク監視MIB(RMON-2)」、RFC2021 1997年1月の[RFC2021]Waldbusser。
[RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2",
RFC 2037, October 1996.
[RFC2037] McCloghrieとK.とA.Bierman、「1996年10月にSMIv2"、RFC2037を使用する実体MIB。」
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D. and K.
McCloghrie, "Definitions of Managed Objects for IEEE
802.3 Repeater Devices using SMIv2", RFC 2108, February
1997.
[RFC2108] deグラーフとK.とRomascanuとD.とマクマスターとD.とK.McCloghrie、「1997年2月にSMIv2"、RFC2108を使用するIEEE802.3リピータデバイスのための管理オブジェクトの定義。」
[RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group
MIB using SMIv2", RFC 2233, November 1997.
[RFC2233] McCloghrie、K.、およびF.Kastenholtz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April
1999.
[RFC2572] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
Bierman & Jones Informational [Page 29] RFC 2922 Physical Topology MIB September 2000
物理的な[29ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)",
RFC 2737, Cisco Systems, December 1999.
[RFC2737]McCloghrieとK.とA.Bierman、「実体MIB(バージョン2)」RFC2737、シスコシステムズ1999年12月。
8. Security Considerations
8. セキュリティ問題
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
There are a number of managed objects in this MIB that may contain sensitive information. These are:
多くの管理オブジェクトが機密情報を含むかもしれないこのMIBにあります。 これらは以下の通りです。
read-create objects: ptopoConnRemoteChassisType
ptopoConnRemoteChassis ptopoConnRemotePortType
ptopoConnRemotePort ptopoConnAgentNetAddrType
ptopoConnAgentNetAddr ptopoConnIsStatic
ptopoConfigTrapInterval ptopoConfigMaxHoldTime
オブジェクトを読書して作成してください: ptopoConnRemoteChassisType ptopoConnRemoteChassis ptopoConnRemotePortType ptopoConnRemotePort ptopoConnAgentNetAddrType ptopoConnAgentNetAddr ptopoConnIsStatic ptopoConfigTrapInterval ptopoConfigMaxHoldTime
read-only objects: ptopoConnDiscAlgorithm
ptopoConnMultiMacSASeen ptopoConnMultiNetSASeen
ptopoConnLastVerifyTime ptopoLastChangeTime
書き込み禁止オブジェクト: ptopoConnDiscAlgorithm ptopoConnMultiMacSASeen ptopoConnMultiNetSASeen ptopoConnLastVerifyTime ptopoLastChangeTime
notifications: ptopoConfigChange
通知: ptopoConfigChange
These MIB objects expose information about the physical connectivity for a particular portion of a network.
これらのMIBオブジェクトはネットワークの特定の部分のための物理的な接続性の情報を暴露します。
Bierman & Jones Informational [Page 30] RFC 2922 Physical Topology MIB September 2000
物理的な[30ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
A network administrator may also wish to inhibit transmission of any ptopoConfigChange notification by setting the ptopoConfigTrapInterval object to zero.
また、ネットワーク管理者は、ptopoConfigTrapIntervalオブジェクトをゼロに設定することによって、どんなptopoConfigChange通知の伝達も抑制したがっているかもしれません。
It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment.
SNMPを通してネットワークの上にそれらを送るとき、その結果、これらのオブジェクトへのGETアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 SNMPのすべてのバージョンがそのような安全な環境のための特徴を提供するというわけではありません。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
それ自体でSNMPv1は安全な環境ではありません。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトがこのMIBに安全なネットワークにだれに許容されているかに関してコントロールが全くありません。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended.
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model RFC2574[RFC2574]とViewのベースのAccess Control Model RFC2575[RFC2575]の使用はお勧めです。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
そして、本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
9. Authors' Addresses
9. 作者のアドレス
Andy Bierman Cisco Systems 170 West Tasman Drive San Jose, CA USA 95134
カリフォルニア米国 アンディBiermanシスコシステムズ170の西タスマン・Driveサンノゼ、95134
Phone: +1 408-527-3711 EMail: abierman@cisco.com
以下に電話をしてください。 +1 408-527-3711 メールしてください: abierman@cisco.com
Kendall S. Jones Nortel Networks 4401 Great America Parkway Santa Clara, CA USA 95054
ケンドールS.ジョーンズノーテルはカリフォルニア米国 4401グレート・アメリカParkwayサンタクララ、95054をネットワークでつなぎます。
Phone: +1 408-495-7356 EMail: kejones@nortelnetworks.com
以下に電話をしてください。 +1 408-495-7356 メールしてください: kejones@nortelnetworks.com
Bierman & Jones Informational [Page 31] RFC 2922 Physical Topology MIB September 2000
物理的な[31ページ]RFC2922トポロジーMIB2000年9月の情報のBiermanとジョーンズ
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bierman & Jones Informational [Page 32]
BiermanとジョーンズInformationalです。[32ページ]
一覧
スポンサーリンク
