[要約] RFC 2922は、ネットワークの物理的なトポロジー情報を管理するためのMIB(Management Information Base)です。このRFCの目的は、ネットワーク管理者がネットワークの物理的な構成を把握し、トラブルシューティングや最適化を行うための情報を提供することです。

Network Working Group                                         A. Bierman
Request for Comments: 2922                           Cisco Systems, Inc.
Category: Informational                                         K. Jones
                                                         Nortel Networks
                                                          September 2000
        

Physical Topology MIB

物理的なトポロジMIB

Status of this 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)The Internet Society(2000)。無断転載を禁じます。

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.

このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用するための管理情報ベース(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
      5 Intellectual Property ...........................................27
   6 Acknowledgements ................................................28
   7 References ......................................................28
   8 Security Considerations .........................................30
   9 Authors' Addresses ..............................................31
   10 Full Copyright Statement .......................................32
        
1. The SNMP Network Management Framework
1. SNMPネットワーク管理フレームワーク

The SNMP Management Framework presently consists of five major components:

SNMP管理フレームワークは現在、5つの主要なコンポーネントで構成されています。

o An overall architecture, described in RFC 2571 [RFC2571].

o RFC 2571 [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 管理を目的としたオブジェクトとイベントを説明および名前を付けるためのメカニズム。この管理情報の最初のバージョン(SMI)はSMIV1と呼ばれ、STD 16、RFC 1155 [RFC1155]、STD 16、RFC 1212 [RFC1212]およびRFC 1215 [RFC1215]で説明されています。SMIV2と呼ばれる2番目のバージョンは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [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メッセージプロトコルの最初のバージョンはSNMPV1と呼ばれ、STD 15、RFC 1157 [RFC1157]で説明されています。インターネット標準トラックプロトコルではないSNMPメッセージプロトコルの2番目のバージョンは、SNMPV2Cと呼ばれ、RFC 1901 [RFC1901]およびRFC 1906 [RFC1906]で説明されています。メッセージプロトコルの3番目のバージョンはSNMPV3と呼ばれ、RFC 1906 [RFC1906]、RFC 2572 [RFC2572]およびRFC 2574 [RFC2574]で説明されています。

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形式は、STD 15、RFC 1157 [RFC1157]で説明されています。プロトコル操作の2番目のセットと関連するPDU形式は、RFC 1905 [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 RFC 2573 [RFC2573]に記載されている一連の基本的なアプリケーションと、RFC 2575 [RFC2575]で説明されているビューベースのアクセス制御メカニズム。

A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].

現在のSNMP管理フレームワークのより詳細な紹介は、RFC 2570 [RFC2570]にあります。

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.

管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されます。

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は、適切な翻訳を通じて生成できます。結果として生じる翻訳されたMIBは、翻訳が不可能であるためオブジェクトまたはイベントが省略されている場合を除き、意味的に同等でなければなりません(Counter64の使用)。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.

特定の管理ドメインに関連する物理ネットワーク接続を表す標準化された手段が必要です。物理トポロジ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など)にはトポロジメカニズムが存在し、共有メディアイーサネット、スイッチイーサネット、トークンリングなどの他のメディアには独自のメカニズムが存在します。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 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.

物理トポロジ物理トポロジは、OSIスタックのレイヤー1のトポロジモデルである物理レイヤーを表します。物理的なトポロジは、ネットワーク上のデバイスを識別し、それらが物理的に相互接続されている方法で構成されています。このドキュメントの定義により、物理的なトポロジーは、同じデバイス上のポート間の物理的な関係を意味するものではありません。これらの関係を決定するための他の手段(例:エンティティ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.

シャーシシャーシは、他の物理的成分を含む物理的なコンポーネントです。これは、「シャーシ(3)」のentphysicalclass値を持つentphysicalentryによって識別され、ゼロのentphysicalcontainedingが識別されます。シャーシ識別子は、グローバルにユニークなsnmpadminstringで構成されています。

Local Chassis The particular chassis containing the SNMP agent implementing the PTOPO MIB.

ローカルシャーシ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.

接続エンドポイント接続エンドポイントは、単一の物理シャーシ内に含まれる物理ポートで構成されています。

Connection Endpoint Identifier A connection endpoint is identified by a globally unique chassis identifier and a port identifier unique within the associated chassis.

接続エンドポイント識別子接続エンドポイントは、関連するシャーシ内でユニークなグローバルに一意のシャーシ識別子とポート識別子によって識別されます。

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.

接続接続は、2つの物理ポートと、ポート間でネットワークトラフィックを転送する目的で構成されている付加された物理媒体で構成されています。接続は、エンドポイント識別子によって識別されます。

Non-local Connection A connection for which neither endpoint is located on the local chassis.

非ローカル接続どちらのエンドポイントもローカルシャーシ上に配置されていない接続。

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をサポートできる少なくとも1つの標準ディスカバリープロトコルを定義する必要があります。単純で拡張可能なディスカバリープロトコルが利用可能でない限り、マルチベンダーの相互運用性は達成できません。ただし、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.

- 既存の標準MIBの重複は、可能な限り利用する必要はありません。物理的トポロジー情報は、インターフェイスMIB [RFC2233]およびエンティティMIB [RFC2737]に見られる機能と密接に結合されています。新しい物理トポロジMIBオブジェクトは、これらのMIBを複製してはなりません。

- 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.

- 識別子安定性接続エンドポイント識別子は永続的でなければなりません(つまり、デバイスの再起動全体で安定します)。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].

- 識別子の柔軟性永続的な文字列ベースのコンポーネント識別子は、多くのソースからサポートする必要があります。シャーシ識別子はエンティティMIB [RFC2737]に記載されており、ポート識別子はインターフェイスMIB [RFC2233]またはエンティティMIB [RFC2737]にあります。

- 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.

- 部分トポロジは、リモートコンポーネントの物理的トポロジーデータをサポートします。エージェントは部分的にのみ利用できます。コンポーネント識別子タイプの列挙された整数階層により、不完全な物理接続識別子情報を、特定のポートに関連付けられたユニキャストソース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.

- 低投票の影響物理トポロジーポーリングは、タイムフィルターデータテーブル(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.

各管理されたデバイスは、使用するように構成されているトポロジメカニズムに基づいて、ネットワークから物理トポロジー情報を収集します。データは、このエージェントの物理ネットワークに関するローカルビューを表しています。収集されたトポロジデータの一部には、追加のトポロジ情報が含まれる可能性のある他のローカルエージェントの識別を含める必要があります。「ローカル」の定義は、使用されているトポロジーメカニズムまたはメカニズムに基づいて異なります。

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.

特定のトポロジメカニズムの多くのインスタンスが特定のネットワークで使用されている可能性があり、多くの異なるメカニズムが採用される場合があります。場合によっては、複数のメカニズムが物理トポロジーの一部で重複する場合があり、個々のポートが複数のトポロジーメカニズムをサポートすることがあります。一般に、これにより、ポートがより堅牢なトポロジ情報を収集できるようになります。エージェントは、ネットワークの任意の部分で使用されているメカニズムを知るように構成する必要がある場合があります。

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.

このセクションでは、物理的なトポロジMIBについて説明して定義します。

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.

特に、エンティティMIB [RFC2737]またはインターフェイスMIB [RFC2233)のオブジェクトは、接続コンポーネント識別子の「参照点」として使用できます。

The Physical Topology MIB uses two identifier types pertaining to the PTOPO MIB:

物理トポロジ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.

識別子は、長さ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.

エンティティMIB [RFC2037]の最初のバージョンでは、物理コンポーネントのインベントリと階層を特定できます。ただし、このMIBは、PTOPO MIBに必要な永続的なコンポーネント識別子を提供しません。したがって、その機能をサポートするには、エンティティ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を実装するエージェントの場合、この新しいオブジェクトを使用してシャーシ識別子を表す必要があります。ポート識別子は、ポートに関連付けられたentphysicalAliasオブジェクトに基づくことができますが、ポートがifxtableのインターフェイスとして表されていない場合のみです。

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]の実装は、PTOPO MIBを実装するSNMPエージェントに必須です。物理的なトポロジー関数をサポートするために、これらのMIBSから他のオブジェクトを実装する必要はありません。

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には、各ポートに永続的な識別子が必要です。インターフェイスMIB [RFC2233]は、ネットワークインターフェイスを管理するための標準的なメカニズムを提供します。残念ながら、PTOPO MIBで表される可能性のあるすべてのポートがインターフェイス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を実装するエージェントの場合、インターフェイスMIBにも表される各ポートについて、エージェントはポート識別子に関連するIFALIAS値を使用する必要があります。インターフェイスMIBで表されていない各ポートについて、関連するentphysicalAlias値をポート識別子に使用する必要があります。PTOPO MIBには、インターフェイスMIBからの最小限のサポートのみが必要であることに注意してください。具体的には、PTOPO MIBでも識別される各ポートに対して、「IfgeneralInformationGroup」レベルの適合性を提供する必要があります。エージェントは、インターフェイス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で識別される物理ポートは、アドレスマップテルにあるMACおよびネットワークレイヤーアドレスに関連している可能性があります。

4.5. Relationship to Bridge MIB
4.5. ブリッジミブとの関係

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に表される物理ポートに関連する情報が含まれています。PTOPO MIBに表されている物理ポートに関連するDOT1DBASEPORTTABLEおよびDOT1DSTPPORTTABLEのエントリ。また、ブリッジポート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.

リピーターMIB [RFC2108]には、PTOPO MIBに表される物理ポートに関連する情報が含まれています。rptrporttableおよびrptrmonitorporttableのエントリは、ptopoconntableに表される物理ポートに関連することによって缶です。RPTRINFOTABLEおよびRPTRMONTABLEのエントリは、PTOPoConntableに表される可能性のあるリピーターバックプレーンに関連する可能性があります。

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は、発見プロトコルおよび/または手動構成から学んだ物理的なトポロジデータを公開します。

- ptopoGeneral Contains general information regarding PTOPO MIB status.

- Ptopoeneralには、PTOPO MIBステータスに関する一般的な情報が含まれています。

- ptopoConfig Contains configuration variables for the PTOPO MIB agent function.

- PTOPOCONFIGには、PTOPO MIBエージェント関数の構成変数が含まれています。

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. ptopoeneralグループ

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情報のステータスを報告するためのいくつかのスカラーオブジェクトが含まれています。グローバルな最後の変更時間とテーブルの追加および削除カウンターにより、NMSがしきい値アラームを設定してPTOPOポーリングをトリガーすることができます。

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.

このグループには、物理トポロジー関数の動作を構成するための表が含まれています。ptopolastchange通知の送信は、ptopoconfigtrapinterval Scalar mibオブジェクトを使用して構成できます。

4.8. Physical Topology MIB Definitions
4.8. 物理トポロジMIB定義
PTOPO-MIB DEFINITIONS ::= BEGIN
        

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

SNMPV2-SMIテキストコンベンションからのモジュールアイデンティティ、オブジェクトタイプ、integer32、counter32、counter32、counter32、mib-2をインポートしてください

FROM SNMPv2-CONF TimeFilter FROM RMON2-MIB PhysicalIndex FROM ENTITY-MIB AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB;

snmpv2-confからrmon2-mib from rmon2-mib fromichedex from entity-mib addressfamilynumbersからiana-address-family-numbers-mibから。

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ワーキンググループ"連絡先INFO "PTOPOMIB WGディスカッション:ptopo@3com.comサブスクリプション:majordomo@33com.com MSGボディ:[UN] Subscribe Ptopomibibib

Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-527-3711 abierman@cisco.com

Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose、CA 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 }
        
ptopoMIBObjects   OBJECT IDENTIFIER ::= { ptopoMIB 1 }
        
-- MIB groups
ptopoData         OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral      OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig       OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }
        
-- textual conventions
PtopoGenAddr ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "The value of an address."
    SYNTAX      OCTET STRING (SIZE (0..20))
        
PtopoChassisIdType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the source of a chassis identifier.
        

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)」は、シャーシコンポーネントのentphysicalaliasの値に基づくシャーシ識別子を表します(すなわち、「シャーシ(3)」のentphysicalclass値)。

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値の値に基づくシャーシ識別子を表します。

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)」は、Conted ChassisのポートのユニキャストソースMACアドレス(ネットワークバイト順序およびIEEE 802.3 Canonical Bit Order)の値に基づくシャーシ識別子を表します。

            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)
    }
        
PtopoChassisId ::= TEXTUAL-CONVENTION
    STATUS      current
    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.
        

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)').

関連するptopophassisidtypeオブジェクトに「chasidentphysicalalias(1)」の値がある場合、オクテット文字列は、シャーシコンポーネントのentphysicalaliasオブジェクトの特定のインスタンスを識別します(すなわち、 'chassis(3)'のentphysicalclass値)。

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.

関連するptopophassisidtypeオブジェクトに「chasidifalias(2)」の値がある場合、Octet stringは、含まれるシャーシ上のインターフェイスの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.

関連するptopophassisidtypeオブジェクトに「chasidportentphysicalalias(3)」の値がある場合、octet stringは、含まれるシャーシ内のポートまたはバックプレーンコンポーネントの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アドレス(ネットワークバイト順序およびIEEE 802.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アドレスファミリ数の列挙値が含まれており、オクテット2からNには、ネットワークバイトの順序でptopogenaddrアドレス値が含まれています。

PtopoPortIdType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the source of a particular type of port
            identifier used in the PTOPO MIB.
        

The enumeration 'portIdIfAlias(1)' represents a port identifier based on the ifAlias MIB object.

列挙「portidifalias(1)」は、iFalias MIBオブジェクトに基づくポート識別子を表します。

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)」は、封じ込めのシャーシ内で、ポートまたはバックプレーンコンポーネントのentphysicalaliasの値(すなわち、「ポート(10)」または「バックプレーン(4)」のentphysicalclass値に基づくポート識別子を表します。

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)
    }
        
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.
        

If the associated PtopoPortIdType object has a value of 'portIdIfAlias(1)', then the octet string identifies a particular instance of the ifAlias object.

関連するptoportidTypeオブジェクトに「portidifalias(1)」の値がある場合、Octet stringは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)').

関連するptoportidtypeオブジェクトに「portidentphysicalalias(2)」の値がある場合、オクテット文字列は、ポートコンポーネントのentphysicalAliasオブジェクトの特定のインスタンスを識別します(つまり、「ポート(10)」のentphysicalclass値)。

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.

関連するptoportidTypeオブジェクトに「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 the PtopoGenAddr address value in network byte order." SYNTAX OCTET STRING (SIZE (1..32))

関連するptoportidtypeオブジェクトに「portidptopogenaddr(4)」の値がある場合、この文字列はポートに関連付けられたネットワークアドレスを識別します。最初のオクテットには、特定のアドレスタイプのIANAアドレスファミリナンバーの列挙値が含まれており、オクテット2からnがネットワークバイト順序でptopogenaddrアドレス値を含んでいます。

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.
        

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)」は、特定のMIBオブジェクトで示されているタイプの1つのソースアドレスが検出されたエントリを表します。

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)」は、(特定のMIBオブジェクトで示されているタイプの)複数のソースアドレスが検出されたエントリを表します。

An agent is expected to set the initial state of the PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'.

エージェントは、ptopoaddrseenstateの初期状態を「notused(1)」または「uncnown(2)」に設定することが期待されます。

            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)
    }
        
--  ***********************************************************
--
--           P T O P O    D A T A     G R O U P
--
--  ***********************************************************
        

-- Connection TableptopoConnTable 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.

- 接続テーブルPTOPOCONNTABLEオブジェクトタイプの構文型PTOPOCONNENTRY MAX-ACCESS NOT-ACCESSABLEステータス現在Ptopoconnentryは、各ローカルポートに存在するか、同じローカルポートに対して複数の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 }
        
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 ::= 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,
      ptopoConnIsStatic            TruthValue,
      ptopoConnLastVerifyTime      TimeStamp,
      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 }
        
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 }
        
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 }
        

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オブジェクトタイプ構文integer32(1..2147483647)最大アクセスアクセス不可能なステータス現在の説明 "このオブジェクトは、このエージェントが特定の接続インスタンスを識別するために使用する任意のローカル整数値を表します。

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
                reboot.  It is considered unlikely that the ptopoConnIndex
            will wrap between reboots."
    ::= { ptopoConnEntry 4 }
        

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.

PTOPOCONNREMOTECHECHASSISTYPEオブジェクトタイプ構文PTOPOCHASSISIDTYPE MAX-ACCESS READ-CREATEステータス現在の説明 "リモート接続エンドポイントに関連付けられているシャーシを識別するために使用されるエンコーディングのタイプ。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 5 }
        

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.

PTOPOCONNREMOTECHECHASSISオブジェクトタイプ構文PTOPOCHASSISID MAX-ACCESS READ-CREATEステータス現在の説明 "リモート接続エンドポイントに関連付けられたシャシーコンポーネントを識別するために使用される文字列値。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 6 }
        

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オブジェクトタイプ構文PTOPOPORTIDTYPE MAX-ACCESS READ-CREATEステータス現在の説明 "関連する「PTOPOCONNREMOTEPORT」オブジェクトで使用されるポート識別子エンコードのタイプ。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 7 }
        

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オブジェクトタイプ構文PTOPOPORTID MAX-ACCESS READ-CREATEステータス現在の説明 "リモート接続エンドポイントに関連付けられているポートコンポーネントを識別するために使用される文字列値。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 8 }
        

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 max-access読み取り専用ステータス現在の説明 "この概念行に含まれる情報を発見するために使用されるアルゴリズムの表示。

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 }
        

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 max-access read-createステータス現在の説明 "このオブジェクトにはゼロ長さの文字列が含まれていない限り、関連するptopoconnnetaddrオブジェクトのこのネットワークアドレスのタイプ。物体。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    ::= { ptopoConnEntry 10 }
        

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 max-access read-createステータス現在の説明 "このオブジェクトは、関連する「ptoponremoteport」に代表されるシャーシおよびポートコンポーネントの情報を含むSNMPエージェントエンティティに到達するために使用できるネットワークアドレスを識別します。'オブジェクト。そのようなアドレスがわからない場合、このオブジェクトには空の文字列が含まれます。

This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)."

関連するptopoconnrowstatusオブジェクトにアクティブの値がある場合、このオブジェクトは変更されない場合があります(1)。」

    ::= { ptopoConnEntry 11 }
        

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オブジェクトタイプの構文PTOPOADDRSEENSTATE MAX-ACCESS READ-ACCESS READ-ACCESS READ-ACCESS ONLY STATUS CURERT CURRET説明 "このオブジェクトは、このエントリの作成以来、リモート接続エンドポイントからエージェントによって複数のユニキャストソースMACアドレスが検出されたかどうかを示します。

If this entry has an associated ptopoConnRemoteChassisType and/or ptopoConnRemotePortType value other than 'portIdMacAddr(3)', then the value 'notUsed(1)' is returned.

このエントリに関連するptopoconnremotechassistypeおよび/またはptopoconnremoteporttype値が「portidmacaddr」以外の値がある場合、値「notused(1)」が返されます。

Otherwise, one of the following conditions must be true:

それ以外の場合、次の条件のいずれかが真実でなければなりません。

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 }
        

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オブジェクトタイプ構文PTOPOADDRSEENSTATE MAX-ACCESS READ-ACCESS READ-ACCESS READ-ONLYステータス現在

If this entry has an associated ptopoConnRemoteChassisType or ptopoConnRemotePortType value other than 'portIdGenAddr(4)' then the value 'notUsed(1)' is returned.

このエントリに関連するptopoconnremotechassistypeまたはptopoconnremoteporttype値が「portidgenaddr(4)」以外の値がある場合、値はnotused(1) 'が返されます。

Otherwise, one of the following conditions must be true:

それ以外の場合、次の条件のいずれかが真実でなければなりません。

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)」が返されます。

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.

エージェントがリモートポートから適切なタイプのネットワークソースアドレスを正確に検出した場合、値「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 }
        

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オブジェクトタイプの構文ruthvalue max-access read-createステータス現在の説明 "このオブジェクトは静的なptopoconnentriesを識別します。このオブジェクトに「true(1)」がある場合、このエントリはエージェント。

If this object has the value 'false(2)', then this entry is subject to all age-out mechanisms implemented by the agent.

このオブジェクトに値「false(2)」がある場合、このエントリはエージェントが実装するすべての年齢のメカニズムの対象となります。

            This object may not be modified if the associated
            ptopoConnRowStatus object has a value of active(1)."
    DEFVAL { false }
    ::= { ptopoConnEntry 14 }
        

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オブジェクトタイプ型構文タイムスタックタイムスタンプMAX-ACCESS READ-ONLYステータス現在の説明 "PToPoconnisStaticの関連する値が「False(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 }
        

ptopoConnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION

ptopoconnrowstatus object-type syntax rowstatus max-access read-createステータス現在の説明

            "The status of this conceptual row."
    ::= { ptopoConnEntry 16 }
        
--  ***********************************************************
--
--           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.

PTOPOLASTCHANGETIMEオブジェクトタイプの構文タイムスタンプMAX-ACCESS READ-ONLYステータス現在の説明 "PTOPoConntableで作成、変更、または削除された概念行が作成、変更、または削除されます。

            An NMS can use this object to reduce polling of the
            ptopoData group objects."
    ::= { ptopoGeneral 1 }
        
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 }
        

ptopoConnTabDeletes OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current

PTOPOCONNTABDELETESオブジェクトタイプ構文カウンター32ユニット "テーブルエントリ" Max-Access読み取り専用ステータス現在

    DESCRIPTION
            "The number of times an entry has been deleted from the
            ptopoConnTable."
    ::= { ptopoGeneral 3 }
        
ptopoConnTabDrops OBJECT-TYPE
    SYNTAX      Counter32
    UNITS       "table entries"
    MAX-ACCESS  read-only
    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 }
        
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 }
        
--  ***********************************************************
--
--           P T O P O    C O N F I G     G R O U P
--
--  ***********************************************************
        

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オブジェクトタイプ構文integer32(0 | 5..3600)ユニット「秒」最大アクセス読み取りワイトステータス現在の説明 "このオブジェクトは、PTOPO通知の送信を制御します。

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.

このオブジェクトにゼロ以外の値がある場合、エージェントは示された期間に複数のptopoconfigchangeトラップイベントを生成してはなりません。「トラップイベント」は、単一の通知PDUタイプの通知宛先のリストに送信されます。。指定されたスロットリング期間内に追加の構成の変更が発生する場合、これらのトラップイベントはエージェントによって抑制されなければなりません。NMSは、ptopolastchangetimeの値を定期的にチェックして、見逃したptopoconfigchangeトラップイベントを検出する必要があります。スロットリングまたは送信の損失による。

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 }
        

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オブジェクトタイプ構文integer32(1..2147483647)ユニット「秒」最大アクセス読み取りワイトステータス現在の説明 "このオブジェクトは、エージェントが動的なptopoconnentriesを維持する目的の時間間隔を指定します。

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.

エントリが最後に検証されてから指定された秒数、新しい検証(トポロジプロトコルメッセージの受信など)がない場合、エージェントはエントリを削除するものとします。エントリは常にすぐに削除されるとは限らないが、定期的なゴミ収集間隔で削除される可能性があることに注意してください。このオブジェクトは、動的なptopoconnentriesのみに影響します。つまり、ptopoconnisstaticが「false(2)」に等しくなります。静的エントリは老化していません。

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>)
        
            where <entry-specific hold-time> is determined by the
            discovery algorithm, and may be different for each entry."
    DEFVAL { 300 }
    ::= { ptopoConfig 2 }
        
-- PTOPO MIB Notification Definitions
ptopoMIBNotifications  OBJECT IDENTIFIER ::= { ptopoMIB 2 }
ptopoMIBTrapPrefix     OBJECT IDENTIFIER ::=
        

{ ptopoMIBNotifications 0 }

{ptopomibnotifications 0}

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.
        
            Note that transmission of ptopoConfigChange notifications
            are throttled by the agent, as specified by the
            'ptopoConfigTrapInterval' object."
   ::= { ptopoMIBTrapPrefix 1 }
        
-- PTOPO Registration Points
ptopoRegistrationPoints  OBJECT IDENTIFIER ::= { ptopoMIB 3 }
        
-- values used with ptopoConnDiscAlgorithm object
ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::=
      { ptopoRegistrationPoints 1 }
        
ptopoDiscoveryLocal      OBJECT IDENTIFIER ::=
      { ptopoDiscoveryMechanisms 1 }
        
-- conformance information
ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 }
        
ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 }
ptopoGroups      OBJECT IDENTIFIER ::= { ptopoConformance 2 }
        
-- 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,
              ptopoGeneralGroup,
              ptopoConfigGroup,
              ptopoNotificationsGroup
        }
    ::= { ptopoCompliances 1 }
        
-- 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.
        
            This group is mandatory for all implementations of the PTOPO
            MIB."
    ::= { ptopoGroups 1 }
        
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.
        
            This group is mandatory for all agents which implement the
            PTOPO MIB."
    ::= { ptopoGroups 2 }
        
ptopoConfigGroup    OBJECT-GROUP
    OBJECTS {
         ptopoConfigTrapInterval,
         ptopoConfigMaxHoldTime
    }
    STATUS  current
    DESCRIPTION
            "The collection of objects which are used to configure the
            PTOPO MIB implementation behavior.
        
            This group is mandatory for agents which implement the PTOPO
            MIB."
    ::= { ptopoGroups 3 }
        
ptopoNotificationsGroup NOTIFICATION-GROUP
    NOTIFICATIONS {
         ptopoConfigChange
    }
    STATUS        current
    DESCRIPTION
            "The collection of notifications used to indicate PTOPO MIB
            data consistency and general status information.
        
            This group is mandatory for agents which implement the PTOPO
            MIB."
    ::= { ptopoGroups 4 }
        

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は、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスに基づく免許にある範囲に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができます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 this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報を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.

[RFC1155] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。

[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.

[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol」、STD 15、RFC 1157、1990年5月。

[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[RFC1212] Rose、M。およびK. McCloghrie、「Concise MIB Definitions」、STD 16、RFC 1212、1991年3月。

[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.

[RFC1215] Rose、M。、「SNMPで使用するためのトラップを定義するための条約」、RFC 1215、1991年3月。

[RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993.

[RFC1493] Decker、E.、Langille、P.、Rijsinghani、A。、およびK. McCloghrie、「ブリッジの管理オブジェクトの定義」、RFC 1493、1993年7月。

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。

[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", January 1996.

[RFC1901] Case、J.、McCloghrie、K.、Rose、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol(SNMPV2)のバージョン2の管理情報の構造」、RFC 1902、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「シンプルネットワーク管理プロトコル(SNMPV2)のバージョン2のテキストコンベンション」、RFC 1903、1996年1月。

[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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol(SNMPV2)のバージョン2の適合ステートメント」、RFC 1904、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol(SNMPV2)のバージョン2のプロトコル操作」、RFC 1905、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol(SNMPV2)のバージョン2の輸送マッピング」、RFC 1906、1996年1月。

[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.

[RFC2021] Waldbusser、S。、「リモートネットワーク監視MIB(RMON-2)」、RFC 2021、1997年1月。

[RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC 2037, October 1996.

[RFC2037] McCloghrie、K。およびA. Bierman、「SMIV2を使用したエンティティMIB」、RFC 2037、1996年10月。

[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 Graaf、K.、Romascanu、D.、McMaster、D。、およびK. McCloghrie、「SMIV2を使用したIEEE 802.3リピーターデバイスの管理オブジェクトの定義」、RFC 2108、1997年2月。

[RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.

[RFC2233] McCloghrie、K。およびF. Kastenholtz、「SMIV2を使用したインターフェースグループMIB」、RFC 2233、1997年11月。

[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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン3の紹介」、RFC 2570、1999年4月。

[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.

[RFC2571] Harrington、D.、Presuhn、R。およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、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] Case、J.、Harrington D.、Presuhn R.およびB. Wijnen、「Simple Network Management Protocol(SNMP)のメッセージ処理とディスパッチ」、RFC 2572、1999年4月。

[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.

[RFC2573] Levi、D.、Meyer、P。and B. Stewart、「SNMPV3 Applications」、RFC 2573、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] Blumenthal、U.およびB. Wijnen、「単純なネットワーク管理プロトコル(SNMPV3)のバージョン3のユーザーベースのセキュリティモデル(USM)」、RFC 2574、1999年4月。

[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、「シンプルネットワーク管理プロトコル(SNMP)のビューベースのアクセス制御モデル(VACM)」、1999年4月、RFC 2575。

[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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「管理情報の構造バージョン2(SMIV2)、STD 58、RFC 2578、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「Smiv2の適合ステートメント」、STD 58、RFC 2580、1999年4月。

[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, Cisco Systems, December 1999.

[RFC2737] McCloghrie、K。およびA. Bierman、「Entity MIB(バージョン2)」、RFC 2737、Cisco Systems、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.

このMIBには、読み取りワイトおよび/またはread-Createの最大アクセス句がある管理オブジェクトがいくつかあります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セキュア環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。

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

読み取りオブジェクト:PTOPOCONNREMOTECHECSISTYPE PTOPOCONNREMOTECHASSIS PTOPOCONNREMOTEPORTTYPE PTOPOCONNREMOTEPORT PTOPOCONTOPONTEPORT PTOPOCONNAGENTNETADDR PTOPOCONNSTATIC PTOPOCONFIGTRAPINTERVALTINTITITIN

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オブジェクトは、ネットワークの特定の部分の物理的な接続性に関する情報を公開します。

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を介してネットワーク上に送信する際にこれらのオブジェクトの値を暗号化することさえ制御することが重要です。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を使用して)安全である場合でも、それでもセキュアネットワークで誰がアクセスして取得/セット(読み取り/変更/作成/削除/削除)を制御することはできません。ミブ。

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.

実装者は、SNMPV3フレームワークで提供されるセキュリティ機能を考慮することをお勧めします。具体的には、ユーザーベースのセキュリティモデルRFC 2574 [RFC2574]およびビューベースのアクセス制御モデルRFC 2575 [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.

SNMPエンティティがこのMIBのインスタンスへのアクセスを提供するSNMPエンティティが、実際に取得または設定する正当な権利を持つプリンシパル(ユーザー)にのみオブジェクトにアクセスできるように適切に構成されていることを保証することは、顧客/ユーザーの責任です(変更を変更します(変更)/作成/削除)それら。

9. Authors' Addresses
9. 著者のアドレス

Andy Bierman Cisco Systems 170 West Tasman Drive San Jose, CA USA 95134

Andy Bierman Cisco Systems 170 West Tasman Drive San Jose、CA 95134

   Phone: +1 408-527-3711
   EMail: abierman@cisco.com
        

Kendall S. Jones Nortel Networks 4401 Great America Parkway Santa Clara, CA USA 95054

ケンドールS.ジョーンズノルテルネットワーク4401グレートアメリカパークウェイサンタクララ、カリフォルニアUSA 95054

   Phone: +1 408-495-7356
   EMail: kejones@nortelnetworks.com
        
10. 完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

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.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

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エディター機能の資金は現在、インターネット協会によって提供されています。