[要約] RFC 3201は、回路からインターフェースへの変換のための管理オブジェクトの定義に関するものであり、回路とインターフェースの間のデータ変換を管理するための標準化を目的としています。

Network Working Group                                     R. Steinberger
Request for Comments: 3201                             Paradyne Networks
Category: Standards Track                                    O. Nicklass
                                            RAD Data Communications Ltd.
                                                            January 2002
        

Definitions of Managed Objects for Circuit to Interface Translation

回路からインターフェース変換のための管理されたオブジェクトの定義

Status of this Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

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

Abstract

概要

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules.

このメモは、TCP/IPベースのインターネットのネットワーク管理プロトコルで使用するための管理情報ベース(MIB)の拡張を定義します。特に、興味深い回路インターフェイスのIFTableへの挿入を管理するためのオブジェクトを定義します。これは、Ifentryを必要とする他のMIBモジュール内で使用する必要がある回路にとって重要です。これにより、回路の統合監視と、変更されていない、既存のMIBモジュールを使用した回路へのルーティングが可能になります。

Table of Contents

目次

   1. The SNMP Management Framework ...............................    2
   2. Conventions .................................................    3
   3. Overview ....................................................    3
   3.1. Circuit Concepts ..........................................    4
   3.2. Theory of Operation .......................................    4
   3.2.1. Creation Process ........................................    4
   3.2.2. Destruction Process .....................................    5
   3.2.2.1. Manual Row Destruction ................................    5
   3.2.2.2. Automatic Row Destruction .............................    5
   3.2.3. Modification Process ....................................    5
   3.2.4. Persistence of Data .....................................    5
   4. Relation to Other MIB Modules ...............................    6
   4.1. Frame Relay DTE MIB .......................................    6
      4.2. Frame Relay Service MIB ...................................    6
   4.3. ATM MIB ...................................................    6
   4.4. Interfaces Group MIB ......................................    6
   4.4.1. Interfaces Table (ifTable, ifXtable) ....................    6
   4.4.2. Stack Table (ifStackTable) ..............................    9
   4.5. Other MIB Modules .........................................   11
   5. Structure of the MIB Module .................................   11
   5.1. ciCircuitTable ............................................   11
   5.2. ciIfMapTable ..............................................   11
   6. Object Definitions ..........................................   11
   7. Acknowledgments .............................................   19
   8. References ..................................................   19
   9. Security Considerations .....................................   21
   10. IANA Considerations ........................................   21
   11. Authors' Addresses .........................................   22
   12. Full Copyright Statement ...................................   23
        
1. The SNMP Management Framework
1. SNMP管理フレームワーク

The SNMP Management Framework presently consists of five major components:

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

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

o RFC 2571 [1]に記載されている全体的なアーキテクチャ。

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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].

o 管理を目的としたオブジェクトとイベントを説明および名前を付けるためのメカニズム。この管理情報構造(SMI)の最初のバージョンはSMIV1と呼ばれ、STD 16、RFC 1155 [2]、STD 16、RFC 1212 [3]およびRFC 1215 [4]で説明されています。SMIV2と呼ばれる2番目のバージョンは、STD 58、RFC 2578 [5]、RFC 2579 [6]、およびRFC 2580 [7]に記載されています。

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 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].

o 管理情報を転送するためのメッセージプロトコル。SNMPメッセージプロトコルの最初のバージョンはSNMPV1と呼ばれ、STD 15、RFC 1157 [8]で説明されています。インターネット標準トラックプロトコルではないSNMPメッセージプロトコルの2番目のバージョンは、SNMPV2Cと呼ばれ、RFC 1901 [9]およびRFC 1906 [10]で説明されています。メッセージプロトコルの3番目のバージョンはSNMPV3と呼ばれ、RFC 1906 [10]、RFC 2572 [11]、およびRFC 2574 [12]で説明されています。

o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].

o 管理情報にアクセスするためのプロトコル操作。プロトコル操作の最初のセットと関連するPDU形式は、STD 15、RFC 1157 [8]で説明されています。プロトコル操作の2番目のセットと関連するPDU形式は、RFC 1905 [13]で説明されています。

o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].

o RFC 2573 [14]に記載されている一連の基本的なアプリケーションと、RFC 2575 [15]で説明されているビューベースのアクセス制御メカニズム。

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

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

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. Conventions
2. 規約

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [21].

キーワードは、このドキュメントに登場する場合、RFC 2119 [21]に記載されているように解釈される場合、必要な、要求されてはならない、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨されない、または推奨されない、または推奨されない、または推奨されてはならない、してはならない、すべきではない、、推奨されてはならない、すべきではない、しないでください。

3. Overview
3. 概要

This MIB module addresses the concept of inserting circuits, which are potentially virtual, into the ifTable. There are multiple reasons to allow circuits to be added to the ifTable. The most prevalent of which are the standard routing MIB tables such as the ipCidrRouteTable (IP-FORWARD-MIB) and the ipNetToMediaTable (IP-MIB) act on the ifIndex and the RMON MIBs (RMON-MIB and RMON2-MIB as defined in RFC 2819 [23] and RFC 2021 [19]) require the use of an ifIndex a DataSource.

このMIBモジュールは、潜在的に仮想である回路をIFTableに挿入するという概念に対処します。iFtableに回路を追加できるようにする理由は複数あります。最も一般的なのは、IPCIDRROTETABLE(IP-Forward-Mib)やIPNettomediatable(IP-MIB)がIFINDEXおよびRMON MIBS(RMON-MIBおよびRMON2-MIBがRFCで定義されているような標準的なルーティングMIBテーブル)などです。2819 [23]およびRFC 2021 [19])は、Ifindex A DataSourceの使用を必要とします。

There is a further need to potentially monitor or manage a circuit based on the directional flow of traffic going through it. For instance, monitoring of protocols passed on a circuit using RMON-II (RFC 2021 [19]) does not currently capture the direction of the flow. This MIB module provides the capability to define an interface based on the specific direction of the flow.

回路を通過する方向性の流れに基づいて、回路を監視または管理する必要があります。たとえば、RMON-II(RFC 2021 [19])を使用して回路で渡されたプロトコルの監視は、現在、流れの方向をキャプチャしません。このMIBモジュールは、フローの特定の方向に基づいてインターフェイスを定義する機能を提供します。

This section provides an overview and background of how to use this MIB module.

このセクションでは、このMIBモジュールの使用方法の概要と背景を説明します。

3.1. Circuit Concepts
3.1. 回路の概念

There are multiple MIB modules that define circuits. Three commonly used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV-MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22]. These define management objects for frame relay DTEs, frame relay services, and ATM respectively. Each of these MIB modules contain the ability to add or delete circuits; however, none create a specific ifEntry for a circuit. The reason for this is that there are potentially multiple circuits and not every circuit needs to be managed as an individual interface. For example, not every circuit on a device needs to be monitored with RMON and not every circuit needs to be included as an individual circuit for routing. Further, the Interfaces Group MIB (RFC 2863) [17] strongly recommends that conceptual rows not be added to the ifTable for virtual circuits.

回路を定義する複数のMIBモジュールがあります。一般的に使用される3つのMIBモジュールは、Frame-Relay-Dte-Mib(RFC 2115)[20]、FrnetServ-Mib(RFC 2954)[18]、およびATM-MIB(RFC 2515)[22]です。これらは、フレームリレーDTE、フレームリレーサービス、およびATMの管理オブジェクトをそれぞれ定義します。これらの各MIBモジュールには、回路を追加または削除する機能が含まれています。ただし、回路の特定のifentryを作成するものはありません。この理由は、潜在的に複数の回路があり、すべての回路を個々のインターフェイスとして管理する必要があるわけではないためです。たとえば、デバイス上のすべての回路をRMONで監視する必要があるわけではなく、すべての回路をルーティングのための個々の回路として含める必要があるわけではありません。さらに、インターフェイスグループMIB(RFC 2863)[17]は、仮想回路のIFTableに概念的行を追加しないことを強く推奨しています。

The rationale for creating conceptual rows in the ifTable for these circuits is that there is a need for their use in either management of routing or monitoring of data. Both of these functions require mapping to an ifIndex.

これらの回路のIFTABLEで概念的行を作成する理由は、ルーティングの管理またはデータの監視のいずれかで使用する必要があるということです。これらの関数は両方とも、ifindexへのマッピングが必要です。

This MIB module is designed such that only those circuits that require an ifIndex need be added to the ifTable. This prevents over-populating the ifTable with useless or otherwise unused indices.

このMIBモジュールは、IFIndexを必要とする回路のみをIFTableに追加する必要があるように設計されています。これにより、役に立たないまたはその他の方法で使用されていないインデックスでIFTableを過度に入力することができます。

While this document often refers to ATM and frame relay, it is not specifically designed for only those types of circuits. Any circuit that is defined in a MIB module but does not have its own ifIndex MAY be added with this MIB module.

このドキュメントは多くの場合、ATMとフレームリレーを指しますが、これらのタイプの回路のみに特有の設計されていません。MIBモジュールで定義されているが、このMIBモジュールで独自のIFINDEXを追加できない回路はすべてです。

3.2. Theory of Operation
3.2. 操作理論
3.2.1. Creation Process
3.2.1. 作成プロセス

In some cases, devices will automatically populate the rows of ciCircuitTable as circuits are created or discovered. However, in many cases, it may be necessary for a network manager to manually create rows.

場合によっては、サーキットが作成または発見されるため、デバイスはCICICRUITTABLEの行を自動的に設定します。ただし、多くの場合、ネットワークマネージャーが手動で行を作成する必要がある場合があります。

Manual creation of rows requires the following steps:

行を手動で作成するには、次の手順が必要です。

1) Locate or create the circuit that is to be added on the device.

1) デバイスに追加する回路を見つけたり作成したりします。

2) Create a row in ciCircuitTable for each flow type that is required.

2) 必要なフロータイプごとにCicircuittableで行を作成します。

The first step above requires some knowledge of the circuits that exist on a device. Typically, logical ports have entries in the ifTable. If, for example, the ifType for the logical port is frameRelay(32), the circuits can be located in the frCircuitTable of the Frame Relay DTE MIB (FRAME-RELAY-DTE-MIB) [18]. If, as another example, the ifType for the logical port is frameRelayService(44), the circuits can be located in the frPVCEndptTable of the Frame Relay Service MIB (FRNETSERV-MIB) [20]. If, as a final example, the ifType for the logical port is aal5(49), the circuits can be located in the aal5VccTable of the ATM MIB (ATM-MIB) [22]. An entry describing the circuit MUST exist in some table prior to creating a row in ciCircuitTable. The object identifier that MUST be used in the circuit definition is the lexicographically smallest accessible OID that fully describes the the circuit.

上記の最初のステップでは、デバイスに存在する回路に関する知識が必要です。通常、論理ポートにはIftableにエントリがあります。たとえば、論理ポートのIFTypeがFramerelay(32)である場合、回路はフレームリレーDTE MIB(Frame-Relay-Dte-Mib)のfrcircuittableに配置できます[18]。別の例として、論理ポートのIFTypeがFramerElayservice(44)である場合、回路はフレームリレーサービスMIB(FRNETSV-MIB)のFRPVESCEDPTTABLEに配置できます[20]。最後の例として、論理ポートのIFTypeがAAL5(49)である場合、回路はATM MIB(ATM-MIB)のAAL5VCCTABLEに配置できます[22]。Cicircuittableで行を作成する前に、回路を説明するエントリがいくつかのテーブルに存在する必要があります。回路定義で使用する必要があるオブジェクト識別子は、回路を完全に記述する辞書的に最小のアクセス可能なOIDです。

3.2.2. Destruction Process
3.2.2. 破壊プロセス
3.2.2.1. Manual Row Destruction
3.2.2.1. 手動の列の破壊

Manual row destruction is straight forward. Any row can be destroyed and the resources allocated to it are freed by setting the value of its status object (ciCircuitStatus) to destroy(6). It should be noted that when ciCircuitStatus is set to destroy(6) all associated rows in the ifTable and in ciIfMapTable will also be destroyed. This process MAY trigger further row destruction in other tables as well.

手動の列の破壊は簡単です。任意の行を破壊することができ、それに割り当てられたリソースは、そのステータスオブジェクト(CICISCUITSTATUS)の値を設定して破壊することで解放されます(6)。CicircuitStatusが(6)IftableおよびCiifmaptableのすべての関連する行も破壊するように設定されている場合、注意する必要があります。このプロセスは、他のテーブルでもさらに列の破壊を引き起こす可能性があります。

3.2.2.2. Automatic Row Destruction
3.2.2.2. 自動列破壊

Rows in the tables MAY be destroyed automatically based on the existence of the circuit on which they rely. When a circuit no longer exists in the device, the data in the tables has no relation to anything known on the network. For this reason, rows MUST be removed from this table as soon as it is discovered that the associated circuits no longer exist. The effects of automatic row destruction are the same as manual row destruction.

テーブル内の行は、依存している回路の存在に基づいて自動的に破壊される場合があります。デバイスに回路が存在しなくなった場合、テーブル内のデータは、ネットワーク上で既知のものとは関係ありません。このため、関連する回路が存在しなくなったことが発見されたらすぐに、このテーブルから行を削除する必要があります。自動列破壊の影響は、手動の列破壊と同じです。

3.2.3. Modification Process
3.2.3. 変更プロセス

Since no objects in the MIB module can be changed once rows are active, there are no modification caveats.

行がアクティブになるとMIBモジュールのオブジェクトを変更できないため、変更の注意事項はありません。

3.2.4. Persistence of Data
3.2.4. データの永続性

Each row in the tables of this MIB module relies on information from other MIB modules. The rules for persistence of the data SHOULD follow the same rules as those of the underlying MIB module. For example, if the circuit defined by ciCircuitObject would normally be stored in non-volatile memory, then the ciCircuitEntry SHOULD also be non-volatile.

このMIBモジュールのテーブルの各行は、他のMIBモジュールからの情報に依存しています。データの永続性のルールは、基礎となるMIBモジュールのルールと同じルールに従う必要があります。たとえば、CicircuitObjectによって定義された回路が通常不揮発性メモリに保存される場合、シシルコントリーも不揮発性である必要があります。

4. Relation to Other MIB Modules
4. 他のMIBモジュールとの関係
4.1. Frame Relay DTE MIB
4.1. フレームリレーDTE MIB

There is no required relation to the Frame Relay DTE MIB beyond the fact that rows in the frCircuitTable MAY be referenced. However, if frCircuitLogicalIfIndex is being used to represent the same information as a ciCircuitEntry with a value of ciCircuitFlow equal to both(3), the implementation MAY use the same ifIndex.

Frcircuittableの行が参照される可能性があるという事実を超えて、フレームリレーDTE MIBとは必要な関係はありません。ただし、FRCIRCUITLOGICALIFINDEXが使用されている場合、両方に等しいCICISCUITFLOWの値を持つCICIRCUITENTRYと同じ情報を表す場合、実装は同じIFINDEXを使用する場合があります。

4.2. Frame Relay Service MIB
4.2. フレームリレーサービスMIB

There is no explicit relation to the Frame Relay Service MIB beyond the fact that a rows in the frPVCEndptTable MAY be referenced.

FRPVendpttableの行が参照される可能性があるという事実を超えて、フレームリレーサービスMIBとの明示的な関係はありません。

4.3. ATM MIB
4.3. ATM MIB

There is no explicit relation to the ATM MIB beyond the fact that rows in multiple tables may be referenced.

複数のテーブルの行が参照される可能性があるという事実を超えて、ATM MIBとの明示的な関係はありません。

4.4. Interfaces Group MIB
4.4. インターフェイスグループMIB
4.4.1. Interfaces Table (ifTable, ifXtable)
4.4.1. インターフェイステーブル(iftable、ifxtable)

The following specifies how the Interfaces Group defined in the IF-MIB will be used for the management of interfaces created by this MIB module.

以下は、IF-MIBで定義されているインターフェイスグループが、このMIBモジュールによって作成されたインターフェイスの管理にどのように使用されるかを指定します。

Values of specific ifTable objects for circuit interfaces are as follows:

回路インターフェイスの特定のIFTableオブジェクトの値は次のとおりです。

   Object Name    Value of Object
   ===========    =====================================================
        

ifIndex Each entry in the circuit table is represented by an ifEntry. The value of ifIndex is defined by the agent such that it complies with any internal numbering scheme.

ifindex回路テーブルの各エントリは、ifentryで表されます。Ifindexの値は、内部番号付けスキームに準拠するようにエージェントによって定義されます。

ifType The value of ifType is specific to the type of circuit desired. For example, the value for frame relay virtual circuits is frDlciEndPt(193) and the value for ATM virtual circuits is atmVciEndPt(194). If the circuit is to be used in RMON, propVirtual(53) SHOULD NOT be used.

IFType IFTypeの値は、必要な回路のタイプに固有です。たとえば、フレームリレー仮想回路の値はFRDLCIENDPT(193)であり、ATM仮想回路の値はATMVCIENDPT(194)です。回路をRMONで使用する場合、PROPVIRTUAL(53)を使用しないでください。

ifMtu Set to the size in octets of the largest packet, frame or PDU supported on the circuit. If this is not known to the ifMtu object shall be set to zero. If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance.

IFMTUは、回路でサポートされている最大のパケット、フレーム、またはPDUのオクテットのサイズに設定します。これが不明な場合は、IFMTUオブジェクトをゼロに設定する必要があります。回路がパケット指向のインターフェイスとしてモデル化されていない場合、このオブジェクトはサポートされず、nosuchinstanceになります。

ifSpeed The peak bandwidth in bits per second available for use. This will equal either the ifSpeed of the logical link if policing is not enforced or the maximum information rate otherwise. If neither is known, the ifSpeed object shall be set to zero.

1秒あたりのビットでピーク帯域幅を使用可能に使用できます。これは、ポリシングが施行されていない場合の論理リンクのIFSSPEEDまたは最大情報レートのいずれかに等しくなります。どちらも知られていない場合、IFSPEEDオブジェクトはゼロに設定するものとします。

ifPhysAddress This will always be an octet string of zero length.

ifphysaddressこれは常にゼロの長さのオクテットの弦になります。

ifInOctets The number of octets received by the network (ingress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifinoctetsこの回路のネットワーク(侵入)が受け取ったオクテットの数。このカウンターは、ヘッダー情報とユーザーデータを含むオクテットのみをカウントする必要があります。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifInUcastPkts The unerrored number of frames, packets or PDUs received by the network (ingress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifinucastpktsこの回路のネットワーク(イングレス)で受信したフレーム、パケット、またはPDUの数字を数えます。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifInDiscards The number of received frames, packets or PDUs for this circuit discarded due to ingress buffer congestion and traffic policing. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

Ifindiscardsは、バッファーの浸透と交通警察のために破棄されたこの回路の受信したフレーム、パケット、またはPDUの数を識別します。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifInErrors The number of received frames, packets or PDUs for this circuit that are discarded because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifinersエラーのために破棄されるこの回路の受信したフレーム、パケット、またはPDUの数。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifOutOctets The number of octets sent by the network (egress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

この回路にネットワーク(出口)から送信されるオクテットの数をifoutoctEts。このカウンターは、ヘッダー情報とユーザーデータを含むオクテットのみをカウントする必要があります。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifOutUcastpkts The number of unerrored frames, packets or PDUs sent by the network (egress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifoutucastpktsこの回路のネットワーク(出口)から送信された未容疑のフレーム、パケット、またはPDUの数。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifOutDiscards The number of frames, packets or PDUs discarded in the egress direction for this circuit. Possible reasons are as follows: policing, congestion. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifoutDiscardsこの回路の出口方向に廃棄されたフレーム、パケット、またはPDUの数。考えられる理由は次のとおりです。ポリシング、混雑。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifOutErrors The number of frames, packets or PDUs discarded for this circuit in the egress direction because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifouterrorは、エラーのために出口方向にこの回路に対して廃棄されたフレーム、パケット、またはPDUの数を装っています。デバイスが回路上の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、Nosuchinstanceになります。

ifInBroadcastPkts If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.

ifinbroadcastPktsデバイスが回路の統計をサポートしていない場合、このオブジェクトをサポートしてはならず、nosuchinstanceになります。

ifOutBroadcastPkts If the device does not support Broadcast packets on the circuit, this object should not be supported and result in noSuchInstance.

ifoutBroadCastPktsデバイスが回路上のブロードキャストパケットをサポートしていない場合、このオブジェクトをサポートしておらず、Nosuchinstanceになります。

ifLinkUpDownTrapEnable Set to false(2). Circuits often have a predefined notification mechanism. In such instances, the number of notification sent would be doubled if this were enabled.

false(2)に設定されたiflinkupdowntrapenableセット。回路には多くの場合、事前定義された通知メカニズムがあります。そのような場合、これが有効になった場合、送信される通知の数は2倍になります。

ifPromiscuousMode Set to false(2). If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance.

ifpromiscuurtyModeがfalseに設定されています(2)。回路がパケット指向のインターフェイスとしてモデル化されていない場合、このオブジェクトはサポートされず、nosuchinstanceになります。

ifConnectorPresent Set to false(2).

ifconnectorPresentはfalseに設定されています(2)。

All other values are supported as stated in the IF-MIB documentation.

他のすべての値は、IF-MIBドキュメントに記載されているようにサポートされています。

4.4.2. Stack Table (ifStackTable)
4.4.2. スタックテーブル(ifstacktable)

This section describes by example how to use ifStackTable to represent the relationship between circuit and logical link interfaces.

このセクションでは、IFStackTableを使用して回路と論理リンクインターフェイスの関係を表す方法の例で説明します。

Example 1: Circuits (C) on a frame relay logical link.

例1:フレームリレーの論理リンク上の回路(c)。

        +---+  +---+  +---+
        | C |  | C |  | C |
        +-+-+  +-+-+  +-+-+
          |      |      |
      +---+------+------+---+
      | Frame Relay Service |
      +----------+----------+
                 |
      +----------+----------+
      |   Physical Layer    |
      +---------------------+
        

The assignment of the index values could for example be (for a V35 physical interface):

インデックス値の割り当ては、たとえば(V35物理インターフェイスの場合)になる可能性があります。

         ifIndex  Description
         =======  ===========
            1     frDlciEndPt       (type 193)
            2     frDlciEndPt       (type 193)
            3     frDlciEndPt       (type 193)
            4     frameRelayService (type 44)
            5     v35               (type 33)
        

The ifStackTable is then used to show the relationships between each interface.

IfStackTableを使用して、各インターフェイス間の関係を表示します。

         HigherLayer   LowerLayer
         ===========   ==========
              0             1
              0             2
              0             3
              1             4
              2             4
              3             4
              4             5
              5             0
        

In the above example the frame relay logical link could just as easily be of type frameRelay(32) instead.

上記の例では、フレームリレーロジカルリンクは、代わりにFramerelay(32)タイプのタイプである可能性があります。

Example 2: Circuits (C) on a AAL5 logical link.

例2:AAL5論理リンク上のサーキット(c)。

           +---+  +---+  +---+
           | C |  | C |  | C |
           +-+-+  +-+-+  +-+-+
             |      |      |
         +---+------+------+---+
         |      AAL5 Layer     |
         +----------+----------+
                    |
         +----------+----------+
         |      ATM Layer      |
         +---------------------+
                    |
         +----------+----------+
         |   Physical Layer    |
         +---------------------+
        

The assignment of the index values could for example be (for a DS3 physical interface):

インデックス値の割り当ては、たとえば(DS3物理インターフェイスの場合)になる可能性があります。

         ifIndex  Description
         =======  ===========
            1     atmVciEndPt (type 194)
            2     atmVciEndPt (type 194)
            3     atmVciEndPt (type 194)
            4     aal5        (type 49)
            5     atm         (type 37)
            6     ds3         (type 30)
        

The ifStackTable is then used to show the relationships between each interface.

IfStackTableを使用して、各インターフェイス間の関係を表示します。

         HigherLayer   LowerLayer
         ===========   ==========
              0             1
              0             2
              0             3
              1             4
              2             4
              3             4
              4             5
              5             6
              6             0
        
4.5. Other MIB Modules
4.5. 他のMIBモジュール

There is no explicit relation to any other media specific MIB module beyond the fact that rows in multiple tables may be referenced.

複数のテーブルの行が参照される可能性があるという事実を超えて、他のメディア固有のMIBモジュールとの明示的な関係はありません。

5. Structure of the MIB Module
5. MIBモジュールの構造

The CIRCUIT-IF-MIB consists of the following components:

回路-if-mibは、次のコンポーネントで構成されています。

o ciCircuitTable

o ciCircuittable

o ciIfMapTable

o ciifmaptable

Refer to the compliance statement defined within for a definition of what objects MUST be implemented.

どのオブジェクトを実装する必要があるかの定義については、定義されたコンプライアンスステートメントを参照してください。

5.1. ciCircuitTable
5.1. ciCircuittable

The ciCircuitTable is the central control table for operations of the Circuit Interfaces MIB. It provides a means of mapping a circuit to its ifIndex as well as forcing the insertion of an ifIndex into the ifTable. The agent is responsible for managing the ifIndex itself such that no device dependent indexing scheme is violated.

Cicircuittableは、回路インターフェイスMIBの操作のための中央制御テーブルです。IFIndexに回路をマッピングする手段と、IFIndexのIFTableへの挿入を強制する手段を提供します。エージェントは、デバイスに依存するインデックススキームが違反されないように、IFINDEX自体を管理する責任があります。

A row in this table MUST exist in order for a row to exist in any other table in this MIB module.

このテーブルには、このMIBモジュールの他のテーブルに行が存在するためには、存在する必要があります。

5.2. ciIfMapTable
5.2. ciifmaptable

This table maps the ifIndex back to the circuit that it is associated with.

このテーブルは、Ifindexを関連付けられている回路に戻します。

6. Object Definitions
6. オブジェクト定義
CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN
        
IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    mib-2, Gauge32                          FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, RowStatus,
    TimeStamp, RowPointer, StorageType      FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP         FROM SNMPv2-CONF
    ifIndex, InterfaceIndex                 FROM IF-MIB;
        

circuitIfMIB MODULE-IDENTITY LAST-UPDATED "200201030000Z" -- January 3, 2002 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO

circuitifmibモジュールのアイデンティティ最後の「200201030000z」 - 2002年1月3日組織「IETFフレームリレーサービスMIBワーキンググループ "連絡先INFO

"IETF Frame Relay Service MIB (frnetmib) Working Group

「IETFフレームリレーサービスMIB(FRNETMIB)ワーキンググループ

           WG Charter:    http://www.ietf.org/html.charters/
                                 frnetmib-charter.html
           WG-email:      frnetmib@sunroof.eng.sun.com
           Subscribe:     frnetmib-request@sunroof.eng.sun.com
           Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib
        

Chair: Andy Malis Vivace Networks Email: Andy.Malis@vivacenetworks.com

椅子:Andy Malis Vivace Networksメール:andy.malis@vivacenetworks.com

WG editor: Robert Steinberger Paradyne Networks and Fujitsu Network Communications Email: robert.steinberger@fnc.fujitsu.com

WG編集者:Robert Steinberger Paradyne Networks and Fujitsu Network Communicationsメール:robert.steinberger@fnc.fujitsu.com

           Co-author:  Orly Nicklass
                       RAD Data Communications Ltd.
           EMail:      Orly_n@rad.co.il"
        DESCRIPTION
            "The MIB module to allow insertion of selected circuit into
             the ifTable."
        REVISION "200201030000Z" -- January 3, 2002
        DESCRIPTION
            "Initial version, published as RFC 3201"
        ::= { mib-2 94 }
        

-- Textual Conventions

- テキストの慣習

    CiFlowDirection ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION
            "The direction of data flow thru a circuit.
        
                transmit(1) - Only transmitted data
                receive(2)  - Only received data
                both(3)     - Both transmitted and received data."
        SYNTAX  INTEGER {
                  transmit(1),
                  receive(2),
                  both(3)
                }
        
    ciObjects      OBJECT IDENTIFIER ::= { circuitIfMIB 1 }
    ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 }
    ciConformance  OBJECT IDENTIFIER ::= { circuitIfMIB 3 }
        
    -- The Circuit Interface Circuit Table
    --
    -- This table is used to define and display the circuits that
    -- are added to the ifTable.  It maps circuits to their respective
    -- ifIndex values.
        
    ciCircuitTable  OBJECT-TYPE
        SYNTAX      SEQUENCE OF CiCircuitEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The Circuit Interface Circuit Table."
        ::= { ciObjects 1 }
        
    ciCircuitEntry OBJECT-TYPE
        SYNTAX      CiCircuitEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "An entry in the Circuit Interface Circuit Table."
        INDEX    { ciCircuitObject, ciCircuitFlow }
        ::= { ciCircuitTable 1 }
        
    CiCircuitEntry ::=
        SEQUENCE {
            --
            -- Index Control Variables
            --
            ciCircuitObject      RowPointer,
            ciCircuitFlow        CiFlowDirection,
            ciCircuitStatus      RowStatus,
            --
            -- Data variables
            --
            ciCircuitIfIndex     InterfaceIndex,
            ciCircuitCreateTime  TimeStamp,
            --
            -- Data Persistence
            --
            ciCircuitStorageType StorageType
        }
        

ciCircuitObject OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains the RowPointer that uniquely

CicircuitObject object-Type構文ROWPOINTER MAX-ACCESS NOT-ACCESSABLEステータス現在の説明 "この値には、ユニークなRowPointerが含まれています

describes the circuit that is to be added to this table. Any RowPointer that will force the size of OBJECT IDENTIFIER of the row to grow beyond the legal limit MUST be rejected.

このテーブルに追加される回路について説明します。行のオブジェクトの識別子のサイズを強制的に強制して、法的制限を超えて成長することを強制する必要があります。

The purpose of this object is to point a network manager to the table in which the circuit was created as well as define the circuit on which the interface is defined.

このオブジェクトの目的は、ネットワークマネージャーに回路が作成されたテーブルを指し、インターフェイスが定義されている回路を定義することです。

             Valid tables for this object include the frCircuitTable
             from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the
             frPVCEndptTable from the Frame Relay Service MIB
             (FRNETSERV-MIB), and the aal5VccTable from the ATM MIB
             (ATM MIB).  However, including circuits from other MIB
             tables IS NOT prohibited."
        ::= { ciCircuitEntry 1 }
        

ciCircuitFlow OBJECT-TYPE SYNTAX CiFlowDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of data flow through the circuit for which the virtual interface is defined. The following define the information that the virtual interface will report.

CICIRCUITFLOWオブジェクトタイプの構文CIFLOWDIRECTION MAX-ACCESS NOT-ACCESSABLEステータス現在の説明 "仮想インターフェイスが定義されている回路を通るデータフローの方向。次のものは、仮想インターフェイスが報告する情報を定義します。

transmit(1) - Only transmitted frames receive(2) - Only received frames both(3) - Both transmitted and received frames.

送信(1) - 送信されたフレームのみを受信します(2) - 受信したフレームの両方(3) - 送信および受信フレームの両方。

             It is recommended that the ifDescr of the circuit
             interfaces that are not both(3) SHOULD have text warning
             the operators that the particular interface represents
             only half the traffic on the circuit."
        ::= { ciCircuitEntry 2 }
        

ciCircuitStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the current row. This object is used to add, delete, and disable rows in this table. When the status changes to active(1), a row will also be added to the interface map table below and a row will be added to the ifTable. These rows SHOULD not be removed until the status is changed from active(1). The value of ifIndex for the row that is added to the ifTable is determined by the agent and MUST follow the rules of the ifTable. The value of ifType for that interface will be frDlciEndPt(193) for a frame relay circuit, atmVciEndPt(194) for an ATM circuit, or another ifType defining the circuit type for any other circuit.

CICIRCUITSTATUSオブジェクトタイプ構文ROWSTATUS MAX-ACCESS READ-CREATEステータス現在の説明 "現在の行のステータス。このオブジェクトは、このテーブルの行を追加、削除、無効にするために使用されます。ステータスがアクティブ(1)に変更されると、行も下のインターフェイスマップ表に追加されると、行がIFTableに追加されます。これらの行は、ステータスがアクティブ(1)から変更されるまで削除しません。Iftableはエージェントによって決定され、Iftableのルールに従う必要があります。そのインターフェイスのIFTypeの値は、フレームリレー回路のFRDLCIENDPT(193)、ATM回路のATMVCiendPT(194)、または回路タイプを定義する別のIFTypeになります。他の回路用。

When this object is set to destroy(6), the associated row in the interface map table will be removed and the ifIndex will be removed from the ifTable. Removing the ifIndex MAY initiate a chain of events that causes changes to other tables as well.

このオブジェクトが破壊されるように設定されると(6)、インターフェイスマップテーブルの関連する行が削除され、IfindexがIftableから削除されます。IFINDEXを削除すると、他のテーブルの変更を引き起こす一連のイベントを開始する場合があります。

The rows added to this table MUST have a valid object identifier for ciCircuitObject. This means that the referenced object must exist and it must be in a table that supports circuits.

このテーブルに追加された行には、CicircuitObjectの有効なオブジェクト識別子が必要です。これは、参照されるオブジェクトが存在する必要があり、回路をサポートするテーブルにある必要があることを意味します。

The object referenced by ciCircuitObject MUST exist prior to transitioning a row to active(1). If at any point the object referenced by ciCircuitObject does not exist or the row containing it is not in the active(1) state, the status SHOULD either age out the row or report notReady(3). The effects transitioning from active(1) to notReady(3) are the same as those caused by setting the status to destroy(6).

CicircuitObjectによって参照されるオブジェクトは、行をアクティブに移行する前に存在する必要があります(1)。CicircuitObjectによって参照されるオブジェクトが存在しない場合、またはそれを含む行がアクティブな状態にない場合、ステータスは行を老化させるか、準備ができていないレポート(3)のいずれかである必要があります。アクティブ(1)からNotrady(3)に移行する効果は、ステータスを破壊するように設定することによって引き起こされる効果と同じです(6)。

             Each row in this table relies on information from other
             MIB modules.  The rules persistence of data SHOULD follow
             the same rules as those of the underlying MIB module.
             For example, if the circuit defined by ciCircuitObject
             would normally be stored in non-volatile memory, then
             the row SHOULD also be non-volatile."
        ::= { ciCircuitEntry 3 }
        
    ciCircuitIfIndex OBJECT-TYPE
        SYNTAX      InterfaceIndex
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The ifIndex that the agent assigns to this row."
        ::= { ciCircuitEntry 4 }
        

ciCircuitCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION

CicircuitCreatetime Object-Type構文タイムスタンプMax-Access読み取り専用ステータス現在の説明

            "This object returns the value of sysUpTime at the time
             the value of ciCircuitStatus last transitioned to
             active(1).  If ciCircuitStatus has never been active(1),
             this object SHOULD return 0."
        ::= { ciCircuitEntry 5 }
        
    ciCircuitStorageType OBJECT-TYPE
        SYNTAX      StorageType
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "The storage type used for this row."
    ::= { ciCircuitEntry 6 }
        
    -- The Circuit Interface Map Table
    --
    -- This table maps the ifIndex values that are assigned to
    -- rows in the circuit table back to the objects that define
    -- the circuits.
        
    ciIfMapTable  OBJECT-TYPE
        SYNTAX      SEQUENCE OF CiIfMapEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The Circuit Interface Map Table."
        ::= { ciObjects 2 }
        
    ciIfMapEntry OBJECT-TYPE
        SYNTAX      CiIfMapEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "An entry in the Circuit Interface Map Table."
        INDEX    { ifIndex }
        ::= { ciIfMapTable 1 }
        
    CiIfMapEntry ::=
        SEQUENCE {
            --
            -- Mapped Object Variables
            --
            ciIfMapObject      RowPointer,
            ciIfMapFlow        CiFlowDirection
        }
        
    ciIfMapObject OBJECT-TYPE
        SYNTAX      RowPointer
            MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "This value contains the value of RowPointer that
             corresponds to the current ifIndex."
        ::= { ciIfMapEntry 1 }
        
    ciIfMapFlow   OBJECT-TYPE
        SYNTAX      CiFlowDirection
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The value contains the value of ciCircuitFlow that
             corresponds to the current ifIndex."
        ::= { ciIfMapEntry 2 }
        

-- Change tracking metrics

- 追跡メトリックを変更します

    ciIfLastChange OBJECT-TYPE
        SYNTAX       TimeStamp
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "The value of sysUpTime at the most recent change to
             ciCircuitStatus for any row in ciCircuitTable."
        ::= { ciObjects 3 }
        
    ciIfNumActive      OBJECT-TYPE
        SYNTAX         Gauge32
        MAX-ACCESS     read-only
        STATUS         current
        DESCRIPTION
            "The number of active rows in ciCircuitTable."
        ::= { ciObjects 4 }
        

-- Conformance Information

- 適合情報

    ciMIBGroups      OBJECT IDENTIFIER ::= { ciConformance 1 }
    ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 }
        

-- -- Compliance Statements --

---コンプライアンスステートメント -

ciCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities

CICComplianceモジュールコンプライアンスステータス現在の説明 "SNMPエンティティのコンプライアンスステートメント

which support of the Circuit Interfaces MIB module. This group defines the minimum level of support required for compliance." MODULE -- this module MANDATORY-GROUPS { ciCircuitGroup, ciIfMapGroup, ciStatsGroup }

回路インターフェイスMIBモジュールのサポート。このグループは、コンプライアンスに必要な最小レベルのサポートレベルを定義しています。」モジュール - このモジュールの必須グループ{CICIRCUITGROUP、CIIFMAPGROUP、CISTATSGROUP}

OBJECT ciCircuitStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Row creation can be done outside of the scope of the SNMP protocol. If this object is implemented with max-access of read-only, then the only value that MUST be returned is active(1)."

オブジェクトCICIRCUITSTATUS SYNTAX INTEGER {Active(1)} - RowStatus MIN-ACCESS READ ONLY説明のサブセット "ROW CREATIONはSNMPプロトコルの範囲外で実行できます。、その後、返さなければならない唯一の値はアクティブです(1)。」

OBJECT ciCircuitStorageType MIN-ACCESS read-only DESCRIPTION "It is legal to support ciCircuitStorageType as read-only as long as the value reported in consistent with the actual storage mechanism employed within the agent."

オブジェクトCICIRCUITSTORAGETYPE MIN-ACCESS読み取り専用説明「エージェント内で採用されている実際のストレージメカニズムと一致する値が報告されている限り、CICICRUITSTORAGETYPEを読み取り専用としてサポートすることは合法です。」

    ::= { ciMIBCompliances 1 }
        
    --
    -- Units of Conformance
    --
    ciCircuitGroup  OBJECT-GROUP
       OBJECTS {
            ciCircuitStatus,
            ciCircuitIfIndex,
            ciCircuitCreateTime,
            ciCircuitStorageType
       }
       STATUS  current
       DESCRIPTION
           "A collection of required objects providing
            information from the circuit table."
       ::= { ciMIBGroups 1 }
        
    ciIfMapGroup OBJECT-GROUP
       OBJECTS {
            ciIfMapObject,
            ciIfMapFlow
       }
           STATUS  current
       DESCRIPTION
           "A collection of required objects providing
            information from the interface map table."
       ::= { ciMIBGroups 2 }
        
    ciStatsGroup OBJECT-GROUP
       OBJECTS {
            ciIfLastChange,
            ciIfNumActive
       }
       STATUS  current
       DESCRIPTION
           "A collection of statistical metrics used to help manage
            the ciCircuitTable."
       ::= { ciMIBGroups 3 }
END
        
7. Acknowledgments
7. 謝辞

This document was produced by the Frame Relay Service MIB Working Group.

このドキュメントは、フレームリレーサービスMIBワーキンググループによって作成されました。

8. References
8. 参考文献

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

[1] Harrington、D.、Presuhn、R。、およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、1999年4月。

[2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.

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

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

[3] Rose、M。and K. McCloghrie、「Scise MIB Definitions」、STD 16、RFC 1212、1991年3月。

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

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

[5] 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.

[5] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。and S. Waldbusser、「管理情報の構造バージョン2(SMIV2)」、STD 58、RFC 2578、1999年4月。

[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[6] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and S. Waldbusser、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。

[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[7] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「Smiv2の適合ステートメント」、Std 58、RFC 2580、1999年4月。

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

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

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

[9] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「コミュニティベースのSNMPV2の紹介」、RFC 1901、1996年1月。

[10] 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.

[10] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル(SNMPV2)のバージョン2の輸送マッピング」、RFC 1906、1996年1月。

[11] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.

[11] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol(SNMP)のメッセージ処理とディスパッチ」、RFC 2572、1999年4月。

[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.

[12] Blumenthal、U.およびB. Wijnen、「シンプルネットワーク管理プロトコル(SNMPV3)のバージョン3のユーザーベースのセキュリティモデル(USM)」、RFC 2574、1999年4月。

[13] 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.

[13] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル(SNMPV2)のバージョン2のプロトコル操作」、RFC 1905、1996年1月。

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

[14] Levi、D.、Meyer、P。and B. Stewart、「SNMPV3 Applications」、RFC 2573、1999年4月。

[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.

[15] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル(SNMP)のビューベースのアクセス制御モデル(VACM)」、RFC 2575、1999年4月。

[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.

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

[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[17] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。

[18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000.

[18] Rehbehn、K。およびD. Fowler、「フレームリレーサービスの管理オブジェクトの定義」、RFC 2954、2000年10月。

[19] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.

[19] Waldbusser、S。、「リモートネットワーク監視管理情報ベースバージョン2を使用したバージョン2」、RFC 2021、1997年1月。

[20] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.

[20] Brown、C。およびF. Baker、「Smiv2を使用したフレームリレーDTEの管理情報ベース」、RFC 2115、1997年9月。

[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[21] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[22] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999.

[22] Tesink、K。、「ATM管理のための管理オブジェクトの定義」、RFC 2515、1999年2月。

[23] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000.

[23] Waldbusser、S。、「リモートネットワーク監視管理情報ベース」、RFC 2819、2000年5月。

9. Security Considerations
9. セキュリティに関する考慮事項

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

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 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended.

実装者は、SNMPV3フレームワークで提供されるセキュリティ機能を考慮することをお勧めします。具体的には、ユーザーベースのセキュリティモデルRFC 2274 [12]およびビューベースのアクセス制御モデルRFC 2275 [15]の使用が推奨されます。

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

10. IANA Considerations
10. IANAの考慮事項
   New ifTypes defined specifically for use in this MIB module SHOULD be
   in the form of ***EndPt.  This is similar to frDlciEndPt(193) and
   atmVciEndPt(194) which are already defined.
        
11. Authors' Addresses
11. 著者のアドレス

Robert Steinberger Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75082

ロバート・スタインバーガー富士通ネットワークコミュニケーション2801テキサス州リチャードソンテキサス75082

Phone: 1-972-479-4739 EMail: robert.steinberger@fnc.fujitsu.com

電話:1-972-479-4739メール:robert.steinberger@fnc.fujitsu.com

Orly Nicklass, Ph.D RAD Data Communications Ltd. 12 Hanechoshet Street Tel Aviv, Israel 69710

Orly Nicklass、Ph.D Rad Data Communications Ltd. 12 Hanechoshet Street Tel Aviv、イスラエル69710

Phone: 972 3 7659969 EMail: Orly_n@rad.co.il

電話:972 3 7659969メール:orly_n@rad.co.il

12. 完全な著作権声明

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

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

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