RFC2020 日本語訳
2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: TXT=72135 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Flick Request for Comments: 2020 Hewlett Packard Category: Standards Track October 1996
コメントを求めるワーキンググループJ.軽打要求をネットワークでつないでください: 2020年のヒューレットパッカードカテゴリ: 標準化過程1996年10月
Definitions of Managed Objects for IEEE 802.12 Interfaces
IEEE802.12インタフェースへの管理オブジェクトの定義
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ............................................... 1 2. Object Definitions ......................................... 2 3. Overview ................................................... 2 3.1. MAC Addresses ............................................ 3 3.2. Relation to RFC 1213 ..................................... 3 3.3. Relation to RFC 1573 ..................................... 3 3.3.1. Layering Model ......................................... 4 3.3.2. Virtual Circuits ....................................... 4 3.3.3. ifTestTable ............................................ 4 3.3.4. ifRcvAddressTable ...................................... 4 3.3.5. ifPhysAddress .......................................... 4 3.3.6. Specific Interface MIB Objects ......................... 5 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 ............. 8 3.5. Relation to RFC 1749 ..................................... 8 3.6. Master Mode Operation .................................... 9 3.7. Normal and High Priority Counters ........................ 9 3.8. IEEE 802.12 Training Frames .............................. 10 3.9. Mapping of IEEE 802.12 Managed Objects ................... 12 4. Definitions ................................................ 14 5. Acknowledgements ........................................... 30 6. References ................................................. 30 7. Security Considerations .................................... 31 8. Author's Address ........................................... 31
1. 序論… 1 2. オブジェクト定義… 2 3. 概要… 2 3.1. MACアドレス… 3 3.2. RFC1213との関係… 3 3.3. RFC1573との関係… 3 3.3.1. レイヤリングモデル… 4 3.3.2. 仮想の回路… 4 3.3.3ifTestTable… 4 3.3.4ifRcvAddressTable… 4 3.3.5ifPhysAddress… 4 3.3.6. 特定のインタフェースMIBは反対します… 5 3.4. RFC1643との関係、RFC1650、およびRFC1748… 8 3.5. RFC1749との関係… 8 3.6. モードが操作であるとマスタリングしてください… 9 3.7. 正常で高い優先度は反対します… 9 3.8. フレームを訓練するIEEE802.12… 10 3.9. IEEE802.12管理オブジェクトに関するマッピング… 12 4. 定義… 14 5. 承認… 30 6. 参照… 30 7. セキュリティ問題… 31 8. 作者のアドレス… 31
1. Introduction
1. 序論
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12.
このメモは使用のために、ネットワーク管理プロトコルでTCP/IPベースのインターネットでManagement Information基地の一部(MIB)を定義します。 特に、それは、IEEE802.12に基づくネットワーク・インターフェースを管理するためにオブジェクトを定義します。
Flick Standards Track [Page 1] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[1ページ]RFC2020IEEE802.12を軽打してください。
2. Object Definitions
2. オブジェクト定義
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. MIB modules are written using a subset of Abstract Syntax Notation One (ASN.1) [1] termed the Structure of Management Information (SMI) [2]. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type.
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 MIBモジュールは、Management情報(SMI)[2]のStructureと呼ばれた抽象的なSyntax Notation One(ASN.1)[1]の部分集合を使用することで書かれています。 特に、各オブジェクト・タイプはOBJECT IDENTIFIER、行政上割り当てられた名前によって命名されます。 オブジェクトインスタンスに伴うオブジェクト・タイプは、唯一オブジェクトの特定の具体化を特定するのに勤めます。 人間の便宜のために、私たちはしばしば記述子と呼ばれた原文のストリングを使用して、オブジェクトについて言及するのはタイプされます。
3. Overview
3. 概要
Instances of these object types represent attributes of an interface to an IEEE 802.12 communications medium. At present, IEEE 802.12 media are identified by one value of the ifType object in the Internet-standard MIB:
これらのオブジェクト・タイプのインスタンスはIEEE802.12コミュニケーション媒体にインタフェースの属性を表します。 現在のところIEEE、802.12のメディアがインターネット標準MIBのifTypeオブジェクトの1つの値によって特定されます:
ieee80212(55)
ieee80212(55)
For this interface, the value of the ifSpecific variable in the MIB- II [5] has the OBJECT IDENTIFIER value:
このインタフェースに関しては、MIB II[5]のifSpecific変数の値には、OBJECT IDENTIFIER値があります:
dot12MIB OBJECT IDENTIFIER ::= { transmission 45 }
dot12MIBオブジェクト識別子:、:= トランスミッション45
The values for the ifType object are defined by the IANAifType textual convention. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers, including new ifType values. Therefore, IANA is responsible for maintaining the definition of this textual convention. The current definition of the IANAifType textual convention is available from IANA's World Wide Web server at:
ifTypeオブジェクトのための値はIANAifTypeの原文のコンベンションによって定義されます。 インターネットAssigned民数記Authority(IANA)は新しいifType値を含むすべてのインターネット番号の課題に責任があります。 したがって、IANAはこの原文のコンベンションの定義を維持するのに責任があります。 IANAifTypeの原文のコンベンションの現在の定義は以下でIANAのWWWサーバから利用可能です。
http://www.iana.org/iana/
http://www.iana.org/iana/
The definitions presented here are based on the IEEE Standard 802.12-1995, [6] Clause 13 "Layer management functions and services", and Annex C "GDMO Specifications for Demand Priority Managed Objects". Implementors of these MIB objects should note that the IEEE document explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here.
ここに提示された定義は[6] IEEE Standard802.12-1995、「層の管理機能とサービス」という第13節、およびAnnex Cに基づいています。「要求優先権管理オブジェクトのためのGDMO仕様。」 これらのMIBオブジェクトの作成者は、IEEEドキュメントが明らかにいつ、どこと様々なMAC属性がどう測定されるかを説明することに(パスカル擬似コードの形で)注意するべきです。 また、IEEEドキュメントはここで定義されたMIBオブジェクトのインスタンスを操ることによって呼び出されるかもしれないMAC動作の効果について説明します。
Flick Standards Track [Page 2] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[2ページ]RFC2020IEEE802.12を軽打してください。
To the extent that some of the attributes defined in [6] are represented by previously defined objects in the Internet-standard MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the MAC address of an interface, and multicast information associated with an interface.
[6]で定義された属性のいくつかがインターネット標準MIB[5]かMIB-II[7]のInterfaces GroupのEvolutionに以前に定義されたオブジェクトによって表されるという範囲には、そのような属性がこのメモで定義されたオブジェクトによって冗長に表されません。 他のメモで定義されたオブジェクトによって表された属性の中に、特定のインタフェースに伝えられるか、または受け取られた八重奏の数、インタフェースに関連しているインタフェース、およびマルチキャスト情報のMACアドレスがあります。
3.1. MAC Addresses
3.1. MACアドレス
All representations of MAC addresses in this MIB module, and in other related MIB modules (like RFC 1573), are in "canonical" order defined by 802.1a, i.e., as if it were transmitted least significant bit first. This is true even if the interface is operating in token ring framing mode, which requires MAC addresses to be transmitted most significant bit first.
このMIBモジュール、および他の関連するMIBモジュール(RFC1573のような)における、MACアドレスのすべての表現が802.1aによって定義された「正準な」オーダーにあります、すなわち、まるで最初にそれが伝えられた最下位ビットであるかのように。 インタフェースが最初にMACアドレスが伝えられた最上位ビットであることを必要とするモードを縁どりながらトークンリングで作動していても、これは本当です。
3.2. Relation to RFC 1213
3.2. RFC1213との関係
This section applies only when this MIB is used in conjunction with the "old" (i.e., pre-RFC 1573) interface group.
このMIBが「古い」(すなわち、RFCのプレ1573)インタフェースグループに関連して使用されるときだけ、このセクションは適用されます。
The relationship between an IEEE 802.12 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein.
インターネット標準MIBの文脈のIEEE802.12インタフェースとインタフェースとの関係は、1〜1です。 そういうものとして、ここに定義されたオブジェクトの対応するインスタンスを特定するのに直接ifIndexオブジェクトインスタンスの値を使用できます。
3.3. Relation to RFC 1573
3.3. RFC1573との関係
RFC 1573, the Interface MIB Evolution, requires that any MIB which is an adjunct of the Interface MIB, clarify specific areas within the Interface MIB. These areas are intentionally left vague in RFC 1573 to avoid over constraining the MIB, thereby precluding management of certain media-types.
RFC1573(Interface MIB Evolution)はそれを必要とします。Interface MIBの付属物であり、Interface MIBの中で特定の領域をはっきりさせるどんなMIB。 これらの領域はMIBを抑制する上で避けるRFC1573年に故意にあいまいなままにされます、その結果、あるメディアタイプの管理を排除します。
An agent which implements this MIB module must support the ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup of RFC 1573.
このMIBモジュールがRFC1573のifGeneralGroup、ifStackGroup、ifHCPacketGroup、およびifRcvAddressGroupをそれの道具にサポートしなければならないエージェント。
Section 3.3 of RFC 1573 enumerates several areas which a media- specific MIB must clarify. In addition, there are some objects in RFC 1573 for which additional clarification of how to apply them to an IEEE 802.12 interface would be helpful. Each of these areas is addressed in a following subsection. The implementor is referred to RFC 1573 in order to understand the general intent of these areas.
RFC1573のセクション3.3はメディアの特定のMIBがはっきりさせなければならないいくつかの領域を列挙します。 さらに、いくつかのオブジェクトがIEEE802.12インタフェースにそれらを付けるのがどう役立っているだろうかに関するどの追加明確化のためにRFC1573にあるか。 それぞれのこれらの領域は次の小区分で扱われます。 作成者は、これらの領域の総合的目的を理解するのにRFC1573を参照されます。
Flick Standards Track [Page 3] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[3ページ]RFC2020IEEE802.12を軽打してください。
3.3.1. Layering Model
3.3.1. レイヤリングモデル
For the typical usage of this MIB module, there will be no sub-layers "above" or "below" the 802.12 Interface. However, this MIB module does not preclude such layering.
このMIBモジュールの典型的な用法のために、“above"か“below"副層は全く802.12にないでしょう。Interface。 しかしながら、このMIBモジュールは、層にしながら、そのようなものを排除しません。
3.3.2. Virtual Circuits
3.3.2. 仮想の回路
This medium does not support virtual circuits and this area is not applicable to this MIB.
この媒体は仮想の回路を支えません、そして、この領域はこのMIBに適切ではありません。
3.3.3. ifTestTable
3.3.3. ifTestTable
This MIB does not define any tests for media instrumented by this MIB. Implementation of the ifTestTable is not required. An implementation may optionally implement the ifTestTable to execute vendor specific tests.
このMIBはこのMIBによって器具を取り付けられたメディアのために少しのテストも定義しません。 ifTestTableの実装は必要ではありません。 実装は、ベンダー特異的な試験を実行するために任意にifTestTableを実装するかもしれません。
3.3.4. ifRcvAddressTable
3.3.4. ifRcvAddressTable
This table contains all IEEE addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for consumption. In addition, when the interface is using 802.5 framing mode, the ifRcvAddressTable will contain the functional address mask.
このテーブルはすべてのIEEEアドレス、ユニキャスト、マルチキャスト、および放送を含んでいます。(このインタフェースは、それのために消費で、より高い層の実体までパケットを受けて、それらを進めるでしょう)。 インタフェースが802.5縁どりモードを使用しているとき、さらに、ifRcvAddressTableは機能アドレスマスクを含むでしょう。
In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism.
インタフェースがMACブリッジの一部であるなら、このテーブルは可能な推進のためにある他のポートから受け入れられるユニキャストアドレスを含んでいません。 明らかに、このテーブルがブリッジアドレスフィルタリングメカニズムを提供することを意図しません。
3.3.5. ifPhysAddress
3.3.5. ifPhysAddress
This object contains the IEEE 802.12 address which is placed in the source-address field of any frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software.
このオブジェクトはこのインタフェースで起因するどんなフレームのソースアドレス分野にも置かれるIEEE802.12アドレスを含んでいます。 通常、これはインタフェースハードウェアの上にROMに保たれるでしょう。 いくつかのシステムがソフトウェアでこのアドレスを設定するかもしれません。
In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems).
そのようないくつかのアドレスがあるシステムでは、デザイナーは、より厳しい選択を持っています。 選ばれたアドレスはネットワークマネージメント(例えば主としてIPシステムであるシステムのためのARP応答に置かれたアドレス)の役に立つ最も傾向があるものであるべきです。
If the designer truly can not choose, use of the factory-provided ROM address is suggested.
デザイナーが本当に選ぶことができないなら、工場によって提供されたROMアドレスの使用は示されます。
If the address can not be determined, an octet string of zero length should be returned.
アドレスが決定できないなら、ゼロ・レングスの八重奏ストリングを返すべきです。
Flick Standards Track [Page 4] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[4ページ]RFC2020IEEE802.12を軽打してください。
The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set. This is true even when the interface is using token ring framing mode, which transmits addresses high-order bit first.
アドレスはこのオブジェクトのバイナリーで保存されます。 アドレスは噛み付いている「正準な」オーダーに保存されます、すなわち、Group Bitが最初の八重奏の下位のビットとして置かれます。 したがって、マルチキャストアドレスの最初のバイトで、ビット0x01を設定するでしょう。 インタフェースがトークンリング縁どりモードを使用してさえいるとき、これが本当である、どれが伝わるかが最初に、高位のビットを扱います。
3.3.6. Specific Interface MIB Objects
3.3.6. 特定のインタフェースMIBオブジェクト
The following table provides specific implementation guidelines for the interface group objects in the conformance groups listed above.
以下のテーブルはインタフェース群対象のための特定の実施要綱を上に記載された順応グループに提供します。
Object Use for an 802.12 Interface
802.12インタフェースのオブジェクト使用
ifIndex Each 802.12 interface is represented by an
ifEntry. Interface tables in this MIB
module are indexed by ifIndex.
ifIndex Each802.12インタフェースはifEntryによって表されます。 このMIBモジュールによるインタフェーステーブルはifIndexによって索引をつけられます。
ifDescr Refer to [7].
ifDescrは[7]について言及します。
ifType The IANA reserved value for 802.12 - 55.
ifType IANAは802.12--55のために値を予約しました。
ifMtu The value of ifMtu on an 802.12 interface
will depend on the type of framing that is
in use on that interface. Changing the
dot12DesiredFramingType may have the effect
of changing ifMtu after the next time that
the interface trains. When
dot12CurrentFramingType is equal to
frameType88023, ifMtu will be equal to
1500. When dot12CurrentFramingType is
equal to frameType88025, ifMtu will be
4464.
802.12のifMtuの値が連結するifMtuはすなわち、そのインタフェースで使用を取り囲むタイプに頼るでしょう。 dot12DesiredFramingTypeを変えるのにおいて、インタフェースが訓練される次回以降ifMtuを変えるという効果があるかもしれません。 dot12CurrentFramingTypeがframeType88023と等しいときに、ifMtuは1500と等しくなるでしょう。 dot12CurrentFramingTypeがframeType88025と等しいときに、ifMtuは4464になるでしょう。
ifSpeed The speed of the interface in bits per
second. For current 802.12
implementations, this will be equal to
100,000,000 (100 million).
bpsにおける、インタフェースの速度をifSpeedしました。 これは現在の802.12の実装に、1億(1億)と等しくなるでしょう。
ifPhysAddress See Section 3.3.5.
ifPhysAddressはセクション3.3.5を見ます。
Flick Standards Track [Page 5] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[5ページ]RFC2020IEEE802.12を軽打してください。
ifAdminStatus Write access is not required. Support for
'testing' is not required. Setting this
object to 'up' will cause dot12Commands to
be set to 'open'. Setting this object to
'down' will cause dot12Commands to be set
to 'close'. Setting dot12Commands to
'open' will set this object to 'up'.
Setting dot12Commands to 'close' will set
this object to 'down'. Setting
dot12Commands to 'reset' will have no
effect on this object.
ifAdminStatus Writeアクセスは必要ではありません。 'テスト'であるサポートは必要ではありません。 このオブジェクトを'up'に設定するのに、'開く'ようにdot12Commandsを用意ができさせるでしょう。 このオブジェクトを'down'に設定するのに、'閉じる'ようにdot12Commandsを用意ができさせるでしょう。 dot12Commandsに'開く'ように設定するのがこのオブジェクトを'up'に設定するでしょう。 dot12Commandsに'閉じる'ように設定するのがこのオブジェクトを'down'に設定するでしょう。 dot12Commandsを設定するのは'リセットする'このオブジェクトの上に効き目がないでしょう。
ifOperStatus When dot12Status is equal to 'opened', this
object will be equal to 'up'. When
dot12Status is equal to 'closed', 'opening',
'openFailure' or 'linkFailure', this object
will be equal to 'down'. Support for
'testing' is not required, but may be used
to indicate that a vendor specific test is
in progress. The value 'dormant' has no
meaning for an IEEE 802.12 interface.
ifOperStatus When dot12Statusが'開かれること'と等しい、このオブジェクトは'up'と等しくなるでしょう。 dot12Statusが'閉じてい'て、'開いている''openFailure'か'linkFailure'と等しいときに、このオブジェクトは'down'と等しくなるでしょう。 'テスト'であるサポートは、必要ではありませんが、ベンダー特異的な試験が進行しているのを示すのに使用されるかもしれません。 値の'眠ること'で、IEEE802.12インタフェースへの意味がありません。
ifLastChange Refer to [7].
ifLastChangeは[7]について言及します。
ifInOctets The number of octets in valid MAC frames
received on this interface, including the
MAC header and FCS.
MACヘッダーとFCSを含んでいて、有効なMACフレームの八重奏の数がこのインタフェースで受けたifInOctets。
ifInUcastPkts Refer to [7].
ifInUcastPktsは[7]について言及します。
ifInDiscards Refer to [7].
ifInDiscardsは[7]について言及します。
ifInErrors The sum for this interface of
dot12InIPMErrors,
dot12InOversizeFrameErrors,
dot12InDataErrors, and any additional
internal errors that may occur in an
implementation.
ifInErrors、dot12InIPMErrors、dot12InOversizeFrameErrors、dot12InDataErrors、および実装で現れるどんな追加内部エラーのこのインタフェースへの合計。
ifInUnknownProtos Refer to [7].
ifInUnknownProtosは[7]について言及します。
ifOutOctets The number of octets transmitted in MAC
frames on this interface, including the MAC
header and FCS.
八重奏の数がMACで伝えたifOutOctetsはMACヘッダーとFCSを含むこのインタフェースで縁どっています。
ifOutUcastPkts Refer to [7].
ifOutUcastPktsは[7]について言及します。
ifOutDiscards Refer to [7].
ifOutDiscardsは[7]について言及します。
Flick Standards Track [Page 6] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[6ページ]RFC2020IEEE802.12を軽打してください。
ifOutErrors The number of implementation-specific
internal transmit errors on this interface.
これにおけるインターナルが伝える実装詳細誤りの数が連結するifOutErrors。
ifName Locally-significant textual name for the
interface (e.g. vg0).
インタフェース(例えば、vg0)へのifName Locally重要な原文の名前。
ifInMulticastPkts Refer to [7]. When dot12CurrentFramingType
is frameType88025, this count includes
packets addressed to functional addresses.
ifInMulticastPktsは[7]について言及します。 dot12CurrentFramingTypeがframeType88025であるときに、このカウントは機能アドレスに扱われたパケットを含んでいます。
ifInBroadcastPkts Refer to [7].
ifInBroadcastPktsは[7]について言及します。
ifOutMulticastPkts Refer to [7]. When dot12CurrentFramingType
is frameType88025, this count includes
packets addressed to functional addresses.
ifOutMulticastPktsは[7]について言及します。 dot12CurrentFramingTypeがframeType88025であるときに、このカウントは機能アドレスに扱われたパケットを含んでいます。
ifOutBroadcastPkts Refer to [7].
ifOutBroadcastPktsは[7]について言及します。
ifHCInOctets 64-bit version of ifInOctets.
ifInOctetsのifHCInOctetsの64ビットのバージョン。
ifHCOutOctets 64-bit version of ifOutOctets
ifOutOctetsのifHCOutOctetsの64ビットのバージョン
ifHC*Pkts Not required for 100 MBit interfaces.
Future IEEE 802.12 interfaces which operate
at higher speeds may require implementation
of these counters, but such interfaces are
beyond the scope of this memo.
ifHC*Pkts Notが100のMBitインタフェースに必要です。 より高い速度で作動する将来のIEEE802.12インタフェースはこれらのカウンタの実装を必要とするかもしれませんが、そのようなインタフェースはこのメモの範囲を超えています。
ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'.
ifLinkUpDownTrapEnableは[7]について言及します。 デフォルトは'可能にされます'。
ifHighSpeed The speed of the interface in millions of
bits per second. For current 802.12
implementations, this will be equal to 100.
何百万ものbpsにおける、インタフェースの速度のifHighSpeed。 これは現在の802.12の実装に、100と等しくなるでしょう。
ifPromiscuousMode Reflects whether the interface has
successfully trained and is currently
operating in promiscuous mode.
dot12DesiredPromiscStatus is used to select
the promiscuous mode to be requested in the
next training attempt. Setting
ifPromiscuousMode will update
dot12DesiredPromiscStatus and cause the
interface to attempt to retrain using the
new promiscuous mode. After the interface
has retrained, ifPromiscuousMode will
reflect the mode that is in use, not the
mode that was requested.
インタフェースが首尾よく訓練して、現在無差別なモードdot12DesiredPromiscStatusで作動しているか否かに関係なく、ifPromiscuousMode Reflectsは、無差別なモードが次のトレーニング試みで要求されているのを選択するのに使用されます。 ifPromiscuousModeを設定するのに、dot12DesiredPromiscStatusをアップデートして、インタフェースは、新しい無差別なモードを使用することで再教育するのを試みるでしょう。 インタフェースが再教育された後に、ifPromiscuousModeは要求されたモードではなく、使用中のモードを反映するでしょう。
Flick Standards Track [Page 7] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[7ページ]RFC2020IEEE802.12を軽打してください。
ifConnectorPresent This will normally be 'true'.
通常、ifConnectorPresent Thisは'本当でしょう'。
ifStackHigherLayer Refer to section 3.3.1
ifStackLowerLayer
ifStackStatus
セクション3.3.1ifStackLowerLayer ifStackStatusへのifStackHigherLayer Refer
ifRcvAddressAddress Refer to section 3.3.4.
ifRcvAddressStatus
ifRcvAddressType
セクション3.3.4ifRcvAddressStatus ifRcvAddressTypeへのifRcvAddressAddress Refer
3.4. Relation to RFC 1643, RFC 1650, and RFC 1748
3.4. RFC1643、RFC1650、およびRFC1748との関係
An IEEE 802.12 interface can be configured to operate in either ethernet or token ring framing mode. An IEEE 802.12 interface uses the frame format for the configured framing mode, but does not use the media access protocol for ethernet or token ring. Instead, IEEE 802.12 defines its own media access protocol, the Demand Priority Access Method (DPAM).
モードを縁どりながらイーサネットかトークンリングのどちらかで作動するためにIEEE802.12インタフェースを構成できます。 IEEE802.12インタフェースは、構成された縁どりモードにフレーム形式を使用しますが、イーサネットかトークンリングにメディアアクセス・プロトコルは使用しません。 代わりに、IEEE802.12はそれ自身のメディアアクセス・プロトコル、Demand Priority Access Method(DPAM)を定義します。
There are existing standards-track MIB modules for instrumenting ethernet-like interfaces and token ring interfaces. At the time of this writing, they are: STD 50, RFC 1643, "Definitions of Managed Objects for Ethernet-like Interface Types" [8]; RFC 1650, "Definitions of Managed Objects for Ethernet-like Interface Types using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10]. These MIB modules are designed to instrument the media access protocol for these respective technologies. Since IEEE 802.12 interfaces do not implement either of these media access protocols, an agent should not implement RFC 1643, RFC 1650, or RFC 1748 for IEEE 802.12 interfaces.
イーサネットのようなインタフェースとトークンリングインタフェースに器具を取り付けるための既存の標準化過程MIBモジュールがあります。 この書くこと時点で、それらは以下の通りです。 STD50、RFC1643、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」[8]。 RFC1650、「SMIv2"[9]を使用しているイーサネットのようなインターフェース型のための管理オブジェクトの定義」。 そして、RFC1748、「SMIv2"[10]を使用するIEEE802.5MIB。」 これらのMIBモジュールはメディアアクセスがこれらのそれぞれの技術のために議定書の中で述べる器具に設計されています。 インタフェースがするIEEE802.12がこれらのどちらのメディアアクセス・プロトコルも実装しないので、エージェントがRFC1643、RFC1650を実装するべきではありませんか、またはIEEE802.12のためのRFC1748は連結します。
3.5. Relation to RFC 1749
3.5. RFC1749との関係
When an IEEE 802.12 interface is operating in token ring framing mode, and the end node supports token ring source routing, the agent should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB [11] for those interfaces.
IEEE802.12インタフェースがモードを縁どりながらトークンリングで作動していて、エンドノードがトークンリングソースルーティングをサポートすると、エージェントはRFC1749(それらのインタフェースへのIEEE802.5駅のSourceルート設定MIB[11])を実装するべきです。
Flick Standards Track [Page 8] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[8ページ]RFC2020IEEE802.12を軽打してください。
3.6. Master Mode Operation
3.6. マスタ・モード操作
In an IEEE 802.12 network, "master" devices act as network controllers to decide when to grant requesting end-nodes permission to transmit. These master devices may be repeaters, or other active controller devices such as switches.
IEEE802.12ネットワークでは、「マスター」デバイスは、いつ伝わるエンドノード許可を要求に与えるかを決めるためにネットワーク制御装置として務めます。 これらのマスターデバイスは、リピータ、またはスイッチなどの他のアクティブなコントローラデバイスであるかもしれません。
Devices which do not act as network controllers, such as end-nodes or passive switches, are considered to be operating in "slave" mode.
エンドノードか受け身のスイッチなどのネットワーク制御装置として務めないデバイスが「奴隷」モードで作動していると考えられます。
The dot12ControlMode object indicates if the interface is operating in master mode or slave mode.
dot12ControlModeオブジェクトは、インタフェースがマスタ・モードかスレーブモードで作動しているかどうかを示します。
3.7. Normal and High Priority Counters
3.7. 正常で高い優先権カウンタ
The IEEE 802.12 interface MIB does not provide normal priority transmit counters. Standardization of normal priority transmit counters could not be justified -- ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should suffice. More precisely, the number of normal priority frames transmitted can be calculated as:
802.12インタフェースMIBが正常な優先権を供給しないIEEEはカウンタを伝えます。 正常な優先権の標準化はカウンタを伝えます。正当化できませんでした--ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutOctets、dot12OutHighPriorityFrames、およびdot12OutHighPriorityOctetsは十分であるはずです。 より正確に、以下としてフレームが伝えた正常な優先権の数について計算できます。
outNormPriorityFrames = ifOutUcastPkts +
ifOutMulticastPkts +
ifOutBroadcastPkts -
dot12OutHighPriorityFrames
outNormPriorityFrames=ifOutUcastPkts+ifOutMulticastPkts+ifOutBroadcastPkts--dot12OutHighPriorityFrames
The number of normal priority octets transmitted can be calculated as:
以下として八重奏が伝えた正常な優先権の数について計算できます。
outNormPriorityOctets = ifOutOctets -
dot12OutHighPriorityOctets
outNormPriorityOctets=ifOutOctets--dot12OutHighPriorityOctets
On the other hand, normal priority receive counters are provided. The main reason for this is that the normal priority and high priority counters include errored frames, whereas the ifIn*Pkts and ifInOctets do not include errored frames. dot12InNormPriorityFrames could be calculated, but the calculation is tedious:
他方では、正常な優先権はカウンタを受けます。提供します。 この主な理由はカウンタが含む正常な優先権と高い優先度がフレームをerroredしましたが、PktsとifInOctetsが含まないifIn*がフレームをerroredしたということです。dot12InNormPriorityFramesについて計算できましたが、計算は退屈です:
inNormPriorityFrames = ifInUcastPkts +
ifInMulticastPkts +
ifInBroadcastPkts +
dot12InNullAddressedFrames +
ifInErrors +
ifInDiscards +
ifInUnknownProtos -
dot12InHighPriorityFrames
inNormPriorityFrames=ifInUcastPkts+ifInMulticastPkts+ifInBroadcastPkts+dot12InNullAddressedFrames+ifInErrors+ifInDiscards+ifInUnknownProtos--dot12InHighPriorityFrames
Flick Standards Track [Page 9] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[9ページ]RFC2020IEEE802.12を軽打してください。
dot12InNormPriorityOctets includes octets in unreadable frames, which is not available elsewhere. The number of octets in unreadable frames can be calculated as:
dot12InNormPriorityOctetsは読みにくいフレームに八重奏を含んでいます(ほかの場所で入手できません)。 以下として読みにくいフレームの八重奏の数について計算できます。
octetsInUnreadableFrames = dot12InNormPriorityOctets +
dot12InHighPriorityOctets -
ifInOctets
octetsInUnreadableFrames=dot12InNormPriorityOctets+dot12InHighPriorityOctets--ifInOctets
Also, the total traffic at this interface can be calculated as:
また、以下としてこのインタフェースの総トラフィックについて計算できます。
traffic = dot12InNormPriorityOctets +
dot12InHighPriorityOctets +
ifOutOctets
トラフィックはdot12InNormPriorityOctets+dot12InHighPriorityOctets+ifOutOctetsと等しいです。
In other words, the normal priority receive counters were deemed useful, whereas the normal priority transmit counters can be easily calculated from other available counters.
言い換えれば、正常な優先権は受信されます。役に立つとカウンタを考えて、正常な優先権は伝わりますが、他の利用可能なカウンタからカウンタについて容易に計算できます。
3.8. IEEE 802.12 Training Frames
3.8. フレームを訓練するIEEE802.12
Training frames are special MAC frames that are used only during link initialization. Training frames are initially constructed by the device at the lower end of a link, which is the slave mode device for the link. The training frame format is as follows:
トレーニングフレームはリンク初期化だけの間に使用される特別なMACフレームです。 トレーニングフレームは初めは、リンクへのスレーブモードデバイスであるリンクの下側の端のデバイスによって建築されます。 トレーニングフレーム形式は以下の通りです:
+----+----+------------+--------------+----------+-----+
| DA | SA | Req Config | Allow Config | Data | FCS |
+----+----+------------+--------------+----------+-----+
+----+----+------------+--------------+----------+-----+ | DA| SA| Reqコンフィグ| コンフィグを許容してください。| データ| FCS| +----+----+------------+--------------+----------+-----+
DA = destination address (six octets)
SA = source address (six octets)
Req Config = requested configuration (2 octets)
Allow Config = allowed configuration (2 octets)
Data = data (594 to 675 octets)
FCS = frame check sequence (4 octets)
DA=送付先アドレス(6つの八重奏)SA=ソースアドレス(6つの八重奏)Req Config=は、(2つの八重奏)が構成(2つの八重奏)データが許容されたConfig=を許容する構成がデータ(594〜675の八重奏)FCS=フレームチェックシーケンスと等しいよう要求しました。(4つの八重奏)
Training frames are always sent with a null destination address. To pass training, an end node must use its source address in the source address field of the training frame. A repeater may use a non-null source address if it has one, or it may use a null source address.
ヌル送付先アドレスと共にトレーニングフレームをいつも送ります。 トレーニングを通過するために、エンドノードはトレーニングフレームのソースアドレス・フィールドでソースアドレスを使用しなければなりません。 それに1つがあるなら、リピータが非ヌルソースアドレスを使用するかもしれませんか、またはそれはヌルソースアドレスを使用するかもしれません。
Flick Standards Track [Page 10] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[10ページ]RFC2020IEEE802.12を軽打してください。
The requested configuration field allows the slave mode device to inform the master mode device about itself and to request configuration options. The training response frame from the master mode device contains the slave mode device's requested configuration from the training request frame. The currently defined format of the requested configuration field as defined in the IEEE Standard 802.12-1995 standard is shown below. Please refer to the most current version of the IEEE document for a more up to date description of this field. In particular, the reserved bits may be used in later versions of the standard.
要求された構成分野で、スレーブモードデバイスは、それ自体に関してマスタ・モードデバイスを知らせて、設定オプションを要求します。 マスタ・モードデバイスからのトレーニングレスポンス・フレームはトレーニング要求フレームからのスレーブモードデバイスの要求された構成を含んでいます。 IEEE Standard802.12-1995規格における定義されるとしての要求された構成分野の現在定義された書式は以下に示されます。 この分野の、より最新の記述のためのIEEEドキュメントの最新版を参照してください。 特に、予約されたビットは規格の後のバージョンで使用されるかもしれません。
First Octet: Second Octet:
最初の八重奏: 第2八重奏:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
vvv: The version of the 802.12 training protocol with which
the training initiator is compliant. The current version
is 100.
r: Reserved bits (set to zero)
FF: 00 = frameType88023
01 = frameType88025
10 = reserved
11 = frameTypeEither
PP: 00 = singleAddressMode
01 = promiscuousMode
10 = reserved
11 = reserved
R: 0 = the training initiator is an end node
1 = the training initiator is a repeater
vvv: トレーニング創始者が言いなりになる802.12トレーニングプロトコルのバージョン。 最新版は100rです: 予約されたビット(ゼロに設定する)FF: 00 = frameType88023 01=frameType88025 10=は11=frameTypeEither PPを予約しました: 00 = promiscuousMode10singleAddressMode01==は予約された11=Rを予約しました: 0 = トレーニング創始者はノード1がトレーニング創始者と等しい終わりがリピータであるということです。
The allowed configuration field allows the master mode device to respond with the allowed configuration. The slave mode device sets the contents of this field to all zero bits. The master mode device sets the allowed configuration field as follows:
許容構成分野で、マスタ・モードデバイスは許容構成で反応します。 スレーブモードデバイスはこの分野のコンテンツをすべてのゼロ・ビットに設定します。 マスタ・モードデバイスは以下の許容構成分野を設定します:
First Octet: Second Octet:
最初の八重奏: 第2八重奏:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
vvv: The version of the 802.12 training protocol with which
the training responder is compliant. The current version
is 100.
vvv: トレーニング応答者が言いなりになる802.12トレーニングプロトコルのバージョン。 最新版は100です。
Flick Standards Track [Page 11] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[11ページ]RFC2020IEEE802.12を軽打してください。
D: 0 = No duplicate address has been detected.
1 = Duplicate address has been detected
C: 0 = The requested configuration is compatible with the
network.
1 = The requested configuration is not compatible with
the network. In this case, the FF, PP, and R bits
indicate the configuration that would be allowed.
N: 0 = Access will be allowed, providing the configuration
is compatible (C = 0).
1 = Access is not granted because of security
restrictions
r: Reserved bits (set to zero)
FF: 00 = frameType88023 will be used
01 = frameType88025 will be used
10 = reserved
11 = reserved
PP: 00 = singleAddressMode
01 = promiscuousMode
10 = reserved
11 = reserved
R: 0 = Requested access as an end node is allowed
1 = Requested access as a repeater is allowed
D: 0 = 写しアドレスは全く検出されていません。 1つの=写しアドレスが検出された、C: 0 = 要求された構成はネットワークと互換性があります。 1 = 要求された構成はネットワークと互換性がありません。 この場合、FF、PP、およびRビットは許されている構成を示します。 N: 0 = 構成は互換性があると(C=0)、アクセスは許されるでしょう。 1 = アクセスは安全保障制限rのために承諾されません: 予約されたビット(ゼロに設定する)FF: 00 = frameType88023は=が予約した予約された中古の10=11がPPであるつもりであったなら中古の01=frameType88025になるでしょう: 00 = promiscuousMode10singleAddressMode01==は予約された11=Rを予約しました: 0 =は、リピータが許容されているとき要求された1=アクセスがエンドノードとしてのアクセスに許されているよう要求しました。
Again, note that the most recent version of the IEEE 802.12 standard should be consulted for the most up to date definition of the requested configuration and allowed configuration fields.
もう一度、IEEE802.12規格の最新のバージョンは大部分のために要求された構成の日付の定義まで相談されて、構成分野を許容されるべきであることに注意してください。
The data field contains between 594 and 675 octets and is filled in by the training initiator. The first 55 octets may be used for vendor specific protocol information. The remaining octets are all zeros. The length of the training frame combined with the requirement that 24 consecutive training frames be received without error to complete training ensures that marginal links will not complete training.
データ・フィールドは、594〜675の八重奏を含んでいて、トレーニング創始者によって記入されます。 最初の55の八重奏がベンダーの特定のプロトコル情報に使用されるかもしれません。 残っている八重奏はすべてゼロです。 訓練するのを完了するために24個の連続したトレーニングフレームが誤りなしで受け取られているという要件に結合されたトレーニングフレームの長さは、マージンのリンクが、訓練するのを完了しないのを確実にします。
3.9. Mapping of IEEE 802.12 Managed Objects
3.9. IEEE802.12管理オブジェクトに関するマッピング
The following table lists all the managed objects defined for oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP objects.
以下のテーブルはIEEE802.12Standard、および対応するSNMPオブジェクトにoEndNodeのために定義されたすべての管理オブジェクトを記載します。
IEEE 802.12 Managed Object Corresponding SNMP Object
IEEE802.12の管理オブジェクトの対応するSNMPオブジェクト
oEndNode
.aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts
.aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts
.aDataErrorFramesReceived dot12InDataErrors
.aDesiredFramingType dot12DesiredFramingType
oEndNode .aBroadcastFramesReceived、-、MIB、--、ifInBroadcastPkts .aBroadcastFramesTransmitted、-、MIB、--、ifOutBroadcastPkts .aDataErrorFramesReceived dot12InDataErrors.aDesiredFramingType dot12DesiredFramingType
Flick Standards Track [Page 12] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[12ページ]RFC2020IEEE802.12を軽打してください。
.aDesiredPromiscuousStatus dot12DesiredPromiscStatus
.aFramesTransmitted IF-MIB - ifOutUCastPkts +
ifOutMulticastPkts +
ifOutBroadcastPkts
.aFramingCapability dot12FramingCapability
.aFunctionalAddresses IF-MIB - ifRcvAddressTable
.aHighPriorityFramesReceived dot12InHighPriorityFrames
.aHighPriorityFramesTransmitted dot12OutHighPriorityFrames
.aHighPriorityOctetsReceived dot12InHighPriorityOctets or
dot12InHCHighPriorityOctets
.aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets or
dot12OutHCHighPriorityOctets
.aIPMFramesReceived dot12InIPMErrors
.aLastTrainingConfig dot12LastTrainingConfig
.aMACID IF-MIB - ifIndex
.aMACStatus dot12Status
.aMACVersion dot12TrainingVersion
.aMediaType <not yet mapped>
Tranceiver MIB issue
.aMulticastFramesReceived IF-MIB - ifInMulticastPkts
.aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts
.aMulticastReceiveStatus IF-MIB - ifRcvAddressTable
.aNormalPriorityFramesReceived dot12InNormPriorityFrames
.aNormalPriorityOctetsReceived dot12InNormPriorityOctets or
dot12InHCNormPriorityOctets
.aNullAddressedFramesReceived dot12InNullAddressedFrames
.aOctetsTransmitted IF-MIB - ifOutOctets or
ifHCOutOctets
.aOversizeFramesReceived dot12InOversizeFrameErrors
.aReadableFramesReceived IF-MIB - ifInUcastPkts +
ifInMulticastPkts +
ifInBroadcastPkts
.aReadableOctetsReceived IF-MIB - ifInOctets or
ifHCInOctets
.aReadMulticastList IF-MIB - ifRcvAddressTable
.aReadWriteMACAddress IF-MIB - ifPhysAddress
.aTransitionsIntoTraining dot12TransitionIntoTrainings
.acAddGroupAddress IF-MIB - ifRcvAddressTable
.acClose dot12Commands: 'close'
.acDeleteGroupAddress IF-MIB - ifRcvAddressTable
.acExecuteSelftest IF-MIB - ifAdminStatus
.acInitializeMAC dot12Commands: 'reset'
.acOpen dot12Commands: 'open'
.aDesiredPromiscuousStatus dot12DesiredPromiscStatus .aFramesTransmitted、-、MIB、--、ifOutUCastPkts+ifOutMulticastPkts+ifOutBroadcastPkts .aFramingCapability dot12FramingCapability .aFunctionalAddresses、-、MIB、--ifRcvAddressTable .aHighPriorityFramesReceived dot12InHighPriorityFrames; aHighPriorityFramesTransmitted dot12OutHighPriorityFrames.aHighPriorityOctetsReceived dot12InHighPriorityOctets、dot12InHCHighPriorityOctets.aHighPriorityOctetsTransmitted dot12OutHighPriorityOctetsまたはdot12OutHCHighPriorityOctets; aIPMFramesReceived dot12InIPMErrors.aLastTrainingConfig dot12LastTrainingConfig .aMACID、-、MIB、--、ifIndex .aMACStatus dot12Status.aMACVersion dot12TrainingVersion .aMediaType<がまだ>Tranceiver MIB問題.aMulticastFramesReceivedを写像していなかった-、MIB、--、ifInMulticastPkts .aMulticastFramesTransmitted、-、MIB、--、ifOutMulticastPkts .aMulticastReceiveStatus、-、MIB、--、ifRcvAddressTable .aNormalPriorityFramesReceived dot12InNormPriorityFrames.aNormalPriorityOctetsReceived dot12InNormPriorityOctetsかdot12InHCNormPriorityOctets .aNullAddressedFramesReceived dot12InNullAddressedFrames .aOctetsTransmitted、-、MIB、--、ifOutOctetsかifHCOutOctets .aOversizeFramesReceived dot12InOversizeFrameErrors .aReadableFramesReceived、-、MIB、--ifInUcastPkts+ifInMulticastPkts+ifInBroadcastPkts; aReadableOctetsReceived、-、MIB、--、ifInOctetsかifHCInOctets .aReadMulticastList、-、MIB、--、ifRcvAddressTable .aReadWriteMACAddress、-、MIB、--、ifPhysAddress .aTransitionsIntoTraining dot12TransitionIntoTrainings .acAddGroupAddress、-、MIB、--、ifRcvAddressTable .acClose dot12Commands: '近い'.acDeleteGroupAddress、-、MIB、--、ifRcvAddressTable .acExecuteSelftest、-、MIB、--、ifAdminStatus .acInitializeMAC dot12Commands: 'リセット'.acOpen dot12Commands: '開いてください'
Flick Standards Track [Page 13] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[13ページ]RFC2020IEEE802.12を軽打してください。
4. Definitions
4. 定義
DOT12-IF-MIB DEFINITIONS ::= BEGIN
DOT12、MIBである、定義:、:= 始まってください。
IMPORTS
transmission, Counter32, Counter64, OBJECT-TYPE,
MODULE-IDENTITY
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
ifIndex
FROM IF-MIB;
IMPORTSトランスミッション、Counter32、Counter64、OBJECT-TYPE、MODULE-IDENTITY FROM SNMPv2-SMI MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM、-、MIB、。
dot12MIB MODULE-IDENTITY
LAST-UPDATED "9602220452Z" -- February 22, 1996
ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group"
CONTACT-INFO
" John Flick
dot12MIBモジュールアイデンティティは1996年2月22日組織「IETF 100VG-AnyLAN MIBワーキンググループ」というコンタクトインフォメーション"9602220452Z"--「ジョンFlick」をアップデートしました。
Postal: Hewlett Packard Company
8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556
Tel: +1 916 785 4018
Fax: +1 916 785 3583
郵便: ヒューレットパッカード会社8000山麓の丘Blvd. S5556ローズビル、M/カリフォルニア95747-5556Tel: +1 916 785、4018Fax: +1 916 785 3583
E-mail: johnf@hprnd.rose.hp.com"
DESCRIPTION
"This MIB module describes objects for
managing IEEE 802.12 interfaces."
::= { transmission 45 }
メール: 「このMIBモジュールはIEEE802.12インタフェースを管理しながら、オブジェクトについて説明する」" johnf@hprnd.rose.hp.com "記述。 ::= トランスミッション45
dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 }
dot12MIBObjectsオブジェクト識別子:、:= dot12MIB1
dot12ConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot12ConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Configuration information for a collection of
802.12 interfaces attached to a particular
system."
::= { dot12MIBObjects 1 }
「802.12のインタフェースの収集のための設定情報は特定のシステムに取り付けた」dot12ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12ConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= dot12MIBObjects1
dot12ConfigEntry OBJECT-TYPE
SYNTAX Dot12ConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
dot12ConfigEntry OBJECT-TYPE SYNTAX Dot12ConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述
Flick Standards Track [Page 14] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[14ページ]RFC2020IEEE802.12を軽打してください。
"Configuration for a particular interface to an
802.12 medium."
INDEX { ifIndex }
::= { dot12ConfigTable 1 }
「802.12媒体への特定のインタフェースへの構成。」 ifIndexに索引をつけてください:、:= dot12ConfigTable1
Dot12ConfigEntry ::=
SEQUENCE {
dot12CurrentFramingType INTEGER,
dot12DesiredFramingType INTEGER,
dot12FramingCapability INTEGER,
dot12DesiredPromiscStatus INTEGER,
dot12TrainingVersion INTEGER,
dot12LastTrainingConfig OCTET STRING,
dot12Commands INTEGER,
dot12Status INTEGER,
dot12ControlMode INTEGER
}
Dot12ConfigEntry:、:= 系列dot12CurrentFramingType整数、dot12DesiredFramingType整数、dot12FramingCapability整数、dot12DesiredPromiscStatus整数、dot12TrainingVersion整数、dot12LastTrainingConfig八重奏ストリング、dot12Commands整数、dot12Status整数、dot12ControlMode整数
dot12CurrentFramingType OBJECT-TYPE
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeUnknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When dot12DesiredFramingType is one of
'frameType88023' or 'frameType88025', this is the
type of framing asserted by the interface.
dot12CurrentFramingType OBJECT-TYPE SYNTAX INTEGER、frameType88023(1)、frameType88025(2)、frameTypeUnknown(3)、「'frameType88025'、dot12DesiredFramingTypeは'frameType88023'のひとりであるかこれはインタフェースによって断言された縁どりのタイプである」マックス-ACCESSの読書だけのSTATUSの現在の記述。
When dot12DesiredFramingType is 'frameTypeEither',
dot12CurrentFramingType shall be one of
'frameType88023' or 'frameType88025' when the
dot12Status is 'opened'. When the dot12Status is
anything other than 'opened',
dot12CurrentFramingType shall take the value of
'frameTypeUnknown'."
::= { dot12ConfigEntry 1 }
dot12DesiredFramingTypeが'frameTypeEither'であるときに、dot12Statusが'開かれる'とき、dot12CurrentFramingTypeは'frameType88023'か'frameType88025'のひとりになるでしょう。 「dot12Statusがそうときに、'開かれること'を除いた何、dot12CurrentFramingTypeでも'frameTypeUnknown'の値を取るものとします。」 ::= dot12ConfigEntry1
dot12DesiredFramingType OBJECT-TYPE
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeEither(3)
}
MAX-ACCESS read-write
STATUS current
dot12DesiredFramingType OBJECT-TYPE SYNTAX INTEGER、frameType88023(1)、frameType88025(2)、マックス-ACCESSがSTATUS海流を読書して書くframeTypeEither(3)
Flick Standards Track [Page 15] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[15ページ]RFC2020IEEE802.12を軽打してください。
DESCRIPTION
"The type of framing which will be requested by
the interface during the next interface MAC
initialization or open action.
記述、「次のインタフェースMAC初期化か開いている動作の間にインタフェースによって要求される縁どりのタイプ。」
In master mode, this is the framing mode which
will be granted by the interface. Note that
for a master mode interface, this object must be
equal to 'frameType88023' or 'frameType88025',
since a master mode interface cannot grant
'frameTypeEither'."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredFramingType."
::= { dot12ConfigEntry 2 }
マスタ・モードで、これはインタフェースによって与えられる縁どりモードです。 「マスタ・モードインタフェースに関して、このオブジェクトが'frameType88023'か'frameType88025'と等しいに違いないことに注意してください、マスタ・モードインタフェースが'frameTypeEither'を与えることができないので。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aDesiredFramingType、」 ::= dot12ConfigEntry2
dot12FramingCapability OBJECT-TYPE
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeEither(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of framing this interface is capable of
supporting."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aFramingCapability."
::= { dot12ConfigEntry 3 }
dot12FramingCapability OBJECT-TYPE SYNTAX INTEGER、frameType88023(1)、frameType88025(2)、frameTypeEither(3)、「このインタフェースを縁どるタイプはサポートすることができる」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aFramingCapability、」 ::= dot12ConfigEntry3
dot12DesiredPromiscStatus OBJECT-TYPE
SYNTAX INTEGER {
singleAddressMode(1),
promiscuousMode(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to select the promiscuous
mode that this interface will request in the next
training packet issued on this interface.
Whether the repeater grants the requested mode
must be verified by examining the state of the PP
bits in the corresponding instance of
dot12LastTrainingConfig.
dot12DesiredPromiscStatus OBJECT-TYPE SYNTAX INTEGER、singleAddressMode(1)、promiscuousMode(2)は「このインタフェースがこのインタフェースで発行された次のトレーニングパケットで要求する無差別なモードを選択するために、使用これが反対するされます」マックス-ACCESSが、STATUS現在の記述を読書して書く。 dot12LastTrainingConfigの対応するインスタンスでPPビットの状態を調べることによって、リピータが要求されたモードを与えるかどうか確かめなければなりません。
Flick Standards Track [Page 16] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[16ページ]RFC2020IEEE802.12を軽打してください。
In master mode, this object controls whether or
not promiscuous mode will be granted by the
interface when requested by the lower level
device.
マスタ・モードで、このオブジェクトは、下のレベルデバイスによって要求されると無差別なモードがインタフェースによって与えられるかどうかを制御します。
Note that this object indicates the desired mode
for the next time the interface trains. The
currently active mode will be reflected in
dot12LastTrainingConfig and in ifPromiscuousMode."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredPromiscuousStatus."
::= { dot12ConfigEntry 4 }
このオブジェクトがインタフェースが訓練される次の時の必要なモードを示すことに注意してください。 「現在アクティブなモードはdot12LastTrainingConfigとifPromiscuousModeに反映されるでしょう。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aDesiredPromiscuousStatus、」 ::= dot12ConfigEntry4
dot12TrainingVersion OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value that will be used in the version bits
(vvv bits) in training frames on this interface.
This is the highest version number supported by
this MAC."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACVersion."
::= { dot12ConfigEntry 5 }
dot12TrainingVersion OBJECT-TYPE SYNTAX INTEGER(0 .7)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「バージョンビット(vvvビット)でトレーニングに使用される値はこのインタフェースで縁どっています」。 「これはこのMACによってサポートされた中で最も大きいバージョン番号です。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aMACVersion、」 ::= dot12ConfigEntry5
dot12LastTrainingConfig OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This 16 bit field contains the configuration
bits from the most recent error-free training
frame received during training on this interface.
Training request frames are received when in
master mode, while training response frames are
received in slave mode. On master mode interfaces,
this object contains the contents of the
requested configuration field of the most recent
training request frame. On slave mode interfaces,
this object contains the contents of the allowed
configuration field of the most recent training
response frame. The format of the current version
of this field is described in section 3.8. Please
refer to the most recent version of the IEEE
802.12 standard for the most up-to-date definition
dot12LastTrainingConfig OBJECT-TYPE SYNTAX OCTET STRING、(「この16ビットの分野はこのインタフェースのトレーニングの間に最新のエラーのないトレーニングフレーム受け取られていた状態で構成ビットを含む」SIZE(2)) MAX-ACCESSの書き込み禁止のSTATUSの現在の記述。 訓練している間、マスタ・モードでは、スレーブモードでレスポンス・フレームを受け取るとき、トレーニング要求フレームは受け取られています。 マスタ・モードインタフェースでは、このオブジェクトは最新のトレーニング要求フレームの要求された構成分野のコンテンツを含んでいます。 スレーブモードインタフェースでは、このオブジェクトは最新のトレーニングレスポンス・フレームの許容構成分野のコンテンツを含んでいます。 この分野の最新版の形式はセクション3.8で説明されます。 最も最新の定義のIEEE802.12規格の最新のバージョンを参照してください。
Flick Standards Track [Page 17] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[17ページ]RFC2020IEEE802.12を軽打してください。
of the format of this object."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aLastTrainingConfig."
::= { dot12ConfigEntry 6 }
「この形式では、反対してください。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aLastTrainingConfig、」、:、:= dot12ConfigEntry6
dot12Commands OBJECT-TYPE
SYNTAX INTEGER {
noOp(1),
open(2),
reset(3),
close(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If the current value of dot12Status is 'closed',
setting the value of this object to 'open' will
change the corresponding instance of MIB-II's
ifAdminStatus to 'up', cause this interface to
enter the 'opening' state, and will cause training
to be initiated on this interface. The progress
and success of the open is given by the values of
the dot12Status object. Setting this object to
'open' when dot12Status has a value other than
'closed' has no effect.
dot12Commands OBJECT-TYPE SYNTAX INTEGER、noOp(1)、戸外(2)、リセット(3)、「dot12Statusの現行価値が'閉じられて'ことであり、このオブジェクトの値に'開く'ように設定するのに、MIB-IIのifAdminStatusの対応するインスタンスを'up'に変えて、このインタフェースが'開いている'状態に入ることを引き起こして、このインタフェースでトレーニングを開始する」ならマックス-ACCESSがSTATUS現在の記述を読書して書く近い(4)。 dot12Statusオブジェクトの値で戸外の進歩と成功を与えます。 このオブジェクトにdot12Statusに'閉じられる'以外の値があるときには'開く'ように設定するのを効き目がありません。
Setting the corresponding instance of ifAdminStatus
to 'up' when the current value of dot12Status is
'closed' will have the same effect as setting this
object to 'open'. Setting ifAdminStatus to 'up'
when dot12Status has a value other than 'closed'
has no effect.
dot12Statusの現行価値が'閉じられる'ときifAdminStatusの対応するインスタンスを'up'に設定するのにおいて、このオブジェクトに'開く'ように設定するのと同じ効果があるでしょう。 dot12Statusに'閉じられる'以外の値があるとき'up'にifAdminStatusを設定するのは効き目がありません。
Setting the value of this object to 'close' will
move this interface into the 'closed' state and
cause all transmit and receive actions to stop.
This object will then have to be set to 'open' in
order to reinitiate training.
このオブジェクトの値に'閉じる'ように設定するのがこのインタフェースをすべてが止まるために動作を送信して、受ける'閉じている'状態と原因に動かすでしょう。 そして、トレーニングを再開始するためにこのオブジェクトが'開く'ように設定されなければならないでしょう。
Setting the corresponding instance of ifAdminStatus
to 'down' will have the same effect as setting this
object to 'close'.
ifAdminStatusの対応するインスタンスを'down'に設定するのにおいて、このオブジェクトに'閉じる'ように設定するのと同じ効果があるでしょう。
Setting the value of this object to 'reset' when
the current value of dot12Status has a value other
than 'closed' will reset the interface. On a
reset, all MIB counters should retain their values.
dot12Statusの現行価値に'閉じられること'を除いた値があるとき、'リセットする'このオブジェクトの値を設定すると、インタフェースはリセットされるでしょう。 リセットのときに、すべてのMIBカウンタがそれらの値を保有するはずです。
Flick Standards Track [Page 18] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[18ページ]RFC2020IEEE802.12を軽打してください。
This will cause the MAC to initiate an
acInitializeMAC action as specified in IEEE 802.12.
This will cause training to be reinitiated on this
interface. Setting this object to 'reset' when
dot12Status has a value of 'closed' has no effect.
Setting this object to 'reset' has no effect on the
corresponding instance of ifAdminStatus.
これで、MACはIEEE802.12で指定されているとしてacInitializeMAC動作を開始するでしょう。 これで、このインタフェースでトレーニングを再開始するでしょう。 dot12Statusに'閉じられること'の値があるとき、このオブジェクトを設定するのは'リセットする'効き目がありません。 このオブジェクトを設定するのは'リセットする'ifAdminStatusの対応するインスタンスで効き目がありません。
Setting the value of this object to 'noOp' has no
effect.
'noOp'にこのオブジェクトの値を設定するのは効き目がありません。
When read, this object will always have a value
of 'noOp'."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.2,
acOpen, acClose, acInitializeMAC.
Also, RFC1231 IEEE802.5 Token Ring MIB,
dot5Commands."
::= { dot12ConfigEntry 7 }
「読まれると、このオブジェクトには、'noOp'の値がいつもあるでしょう。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .2 acOpen、acClose、acInitializeMAC、」 「RFC1231 IEEE802.5トークンリングMIB、dot5Commandsも。」 ::= dot12ConfigEntry7
dot12Status OBJECT-TYPE
SYNTAX INTEGER {
opened(1),
closed(2),
opening(3),
openFailure(5),
linkFailure(6)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current interface status with respect to
training. One of the following values:
dot12Status OBJECT-TYPE SYNTAX INTEGERがマックス-ACCESS書き込み禁止STATUS現在で(1)、閉じた(2)、初めの(3)、openFailure(5)、linkFailure(6)を開いた、記述、「トレーニングに関する現在のインタフェース状態。」 以下の値の1つ:
opened - Training has completed
successfully.
closed - MAC has been disabled by
setting dot12Commands to
'close'.
opening - MAC is in training. Training
signals have been received.
openFailure - Passed 24 error-free packets,
but there is a problem, noted
in the training configuration
bits (dot12LastTrainingConfig).
linkFailure - Training signals not received,
or could not pass 24 error-free
packets.
開かれます--、トレーニングが首尾よく完成した. --開いて、--閉じられて、dot12Commandsに'閉じる'ように設定することによって、MACは無効にされて、MACはトレーニング中です。 トレーニング信号を受信しました。openFailure--24のエラーのないパケットをそこに通過するのは、問題です、ビット(dot12LastTrainingConfig)トレーニング構成linkFailureでは、有名です--トレーニング信号は、24のエラーのないパケットを受けるか、または通過するかもしれません。
Flick Standards Track [Page 19] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[19ページ]RFC2020IEEE802.12を軽打してください。
Whenever the dot12Commands object is set to
'close' or ifAdminStatus is set to 'down', the MAC
will go silent, dot12Status will be 'closed', and
ifOperStatus will be 'down'.
dot12Commandsオブジェクトが'閉じる'ように設定されるか、またはifAdminStatusが'down'に用意ができているときはいつも、MACは静かになるでしょう、そして、dot12Statusは'閉じられるでしょう'、そして、ifOperStatusは'down'になるでしょう。
When the value of this object is equal to 'closed'
and the dot12Commands object is set to 'open' or
the ifAdminStatus object is set to 'up', training
will be initiated on this interface. When the
value of this object is not equal to 'closed' and
the dot12Commands object is set to 'reset',
training will be reinitiated on this interface.
Note that sets of some other objects (e.g.
dot12ControlMode) or external events (e.g. MAC
protocol violations) may also cause training to be
reinitiated on this interface.
このオブジェクトの値が'閉じられること'と等しく、dot12Commandsオブジェクトが'開く'ように設定されるか、またはifAdminStatusオブジェクトが'up'に設定されるとき、トレーニングはこのインタフェースで開始されるでしょう。 このオブジェクトの値が'閉じられること'と等しくなく、dot12Commandsオブジェクトが'リセット'に設定されるとき、トレーニングはこのインタフェースで再開始されるでしょう。 また、ある他のオブジェクト(例えば、dot12ControlMode)か外部のイベント(例えば、MACプロトコル違反)のセットがこのインタフェースでトレーニングを再開始させるかもしれないことに注意してください。
When training is initiated or reinitiated on an
interface, the end node will send Training_Up to
the master and initially go to the 'linkFailure'
state and ifOperStatus will go to 'down'.
When the master sends back Training_Down,
dot12Status will change to the 'opening' state,
and training packets will be transferred.
トレーニングがインタフェースで開始されるか、または再開始されると、エンドノードは、Training_をマスターに上げて、初めは'linkFailure'状態に行くでしょう、そして、ifOperStatusは'down'に行くでしょう。 マスターがTraining_Downを返送するとき、dot12Statusは'開いている'状態に変化するでしょう、そして、トレーニングパケットを移すでしょう。
After all of the training packets have been
passed, dot12Status will change to 'linkFailure'
if 24 consecutive error-free packets were not
passed, 'opened' if 24 consecutive error-free
packets were passed and the training
configuration bits were OK, or 'openFailure' if
there were 24 consecutive error-free packets, but
there was a problem with the training
configuration bits.
トレーニングパケットのすべてが通過された後に、dot12Statusは、24の連続したエラーのないパケットが通過されなかったかどうかを'linkFailure'に変えるでしょう、連続したエラーのないパケットが通過された24とトレーニング構成ビットがOK、または'openFailure'であったなら24の連続したエラーのないパケットがありましたが、トレーニング構成ビットに関する問題があったなら'開かれ'て。
When in the 'openFailure' state, the
dot12LastTrainingConfig object will contain the
configuration bits from the last training
packet which can be examined to determine the
exact reason for the training configuration
failure.
dot12LastTrainingConfigオブジェクトが'openFailure'州にトレーニング構成失敗の正確な理由を決定するために調べることができる最後のトレーニングパケットからの構成ビットを含むと。
If training did not succeed (dot12Status is
'linkFailure' or 'openFailure), the entire
process will be restarted after
MAC_Retraining_Delay_Timer seconds.
トレーニングが成功しなかったなら(dot12Statusは'linkFailure'か'openFailureです)、全体のプロセスがDelay_Timerが後援するMAC_Retraining_の後に再開される、'
If training does succeed (dot12Status changes to
トレーニングが成功する、(dot12Statusは変化します。
Flick Standards Track [Page 20] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[20ページ]RFC2020IEEE802.12を軽打してください。
'opened'), ifOperStatus will change to 'up'. If
training does not succeed (dot12Status changes to
'linkFailure' or 'openFailure'), ifOperStatus will
remain 'down'."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACStatus."
::= { dot12ConfigEntry 8 }
'開き')、ifOperStatusは'up'に変化するでしょう。 「トレーニングが('linkFailure'か'openFailure'へのdot12Status変化)を引き継がないと、ifOperStatusは'down'のままで残るでしょう。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aMACStatus、」 ::= dot12ConfigEntry8
dot12ControlMode OBJECT-TYPE
SYNTAX INTEGER {
masterMode(1),
slaveMode(2),
learn(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to configure and report
whether or not this interface is operating in
master mode. In a Demand Priority network, end
node interfaces typically operate in slave mode,
while switch interfaces may control the Demand
Priority protocol and operate in master mode.
masterMode(1)(slaveMode(2))は(3)を学びます。dot12ControlMode OBJECT-TYPE SYNTAX INTEGER、マックス-ACCESSは「このインタフェースがマスタ・モードで作動しているか否かに関係なく、このオブジェクトは構成して、報告するのにおいて使用されていること」をSTATUSの現在の記述に読書して書きます。 Demand Priorityネットワークでは、エンドノードインタフェースはスレーブモードで通常作動します、スイッチインタフェースが、Demand Priorityプロトコルを制御して、マスタ・モードで作動するかもしれませんが。
This object may be implemented as a read-only
object by those agents and interfaces that do not
implement software control of master mode. In
particular, interfaces that cannot operate in
master mode, and interfaces on which master mode
is controlled by a pushbutton on the device,
should implement this object read-only.
このオブジェクトは書き込み禁止オブジェクトとしてソフトウェアがマスタ・モードのコントロールであると実装しないそれらのエージェントとインタフェースによって実装されるかもしれません。 特に、マスタ・モードで作動できないインタフェース、およびマスタ・モードがデバイスの上のプッシュボタンによって制御されるインタフェースは、このオブジェクトが書き込み禁止であると実装するべきです。
Some interfaces do not require network management
configuration of this feature and can autosense
whether to use master mode or slave mode. The
value 'learn' is used for that purpose. While
autosense is taking place, the value 'learn' is
returned.
いくつかのインタフェースが、この特徴のネットワークマネージメント構成を必要としないで、マスタ・モードを使用するか、そして、スレーブモードをautosenseすることができます。 値の'学習'はそのために使用されます。 autosenseが行われている間、'学んでください'が返される値です。
A network management operation which modifies the
value of dot12ControlMode causes the interface
to retrain."
::= { dot12ConfigEntry 9 }
「dot12ControlModeの値を変更するネットワークマネージメント操作で、インタフェースは再教育されます。」 ::= dot12ConfigEntry9
dot12StatTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot12StatEntry
MAX-ACCESS not-accessible
アクセスしやすくないdot12StatTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12StatEntryマックス-ACCESS
Flick Standards Track [Page 21] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[21ページ]RFC2020IEEE802.12を軽打してください。
STATUS current
DESCRIPTION
"Statistics for a collection of 802.12 interfaces
attached to a particular system."
::= { dot12MIBObjects 2 }
「802.12のインタフェースの収集のための統計は特定のシステムに取り付けた」STATUSの現在の記述。 ::= dot12MIBObjects2
dot12StatEntry OBJECT-TYPE
SYNTAX Dot12StatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics for a particular interface to an
802.12 medium. The receive statistics in this
table apply only to packets received by this
station (i.e., packets whose destination address
is either the local station address, the
broadcast address, or a multicast address that
this station is receiving, unless the station is
in promiscuous mode)."
INDEX { ifIndex }
::= { dot12StatTable 1 }
dot12StatEntry OBJECT-TYPE SYNTAX Dot12StatEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「802.12媒体への特定のインタフェースへの統計。」 「これほどテーブルのコネがこのステーション(すなわち、ステーションが無差別なモードでない場合、送付先アドレスが地方局アドレス、放送演説かこのステーションが受け取っているマルチキャストアドレスのどちらかであるパケット)によって受け取られたパケットだけに適用する統計を受け取ってください、」 ifIndexに索引をつけてください:、:= dot12StatTable1
Dot12StatEntry ::=
SEQUENCE {
dot12InHighPriorityFrames Counter32,
dot12InHighPriorityOctets Counter32,
dot12InNormPriorityFrames Counter32,
dot12InNormPriorityOctets Counter32,
dot12InIPMErrors Counter32,
dot12InOversizeFrameErrors Counter32,
dot12InDataErrors Counter32,
dot12InNullAddressedFrames Counter32,
dot12OutHighPriorityFrames Counter32,
dot12OutHighPriorityOctets Counter32,
dot12TransitionIntoTrainings Counter32,
dot12HCInHighPriorityOctets Counter64,
dot12HCInNormPriorityOctets Counter64,
dot12HCOutHighPriorityOctets Counter64
}
Dot12StatEntry:、:= 系列{ dot12InHighPriorityFrames Counter32、dot12InHighPriorityOctets Counter32、dot12InNormPriorityFrames Counter32、dot12InNormPriorityOctets Counter32、dot12InIPMErrors Counter32、dot12InOversizeFrameErrors Counter32、dot12InDataErrors Counter32; dot12InNullAddressedFrames Counter32、dot12OutHighPriorityFrames Counter32、dot12OutHighPriorityOctets Counter32、dot12TransitionIntoTrainings Counter32、dot12HCInHighPriorityOctets Counter64、dot12HCInNormPriorityOctets Counter64、dot12HCOutHighPriorityOctets Counter64; }
dot12InHighPriorityFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of high priority frames
that have been received on this interface.
Includes both good and bad high priority frames,
dot12InHighPriorityFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた高い優先権フレームのカウントです」。 良いものと同様に悪い高い優先権フレームを含んでいます。
Flick Standards Track [Page 22] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[22ページ]RFC2020IEEE802.12を軽打してください。
as well as high priority training frames. Does
not include normal priority frames which were
priority promoted."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityFramesReceived."
::= { dot12StatEntry 1 }
高い優先権トレーニングフレームと同様に。 「促進された優先権であった正常な優先権フレームを含んでいません。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityFramesReceived、」 ::= dot12StatEntry1
dot12InHighPriorityOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of octets
contained in high priority frames that have been
received on this interface. This counter is
incremented by OctetCount for each frame received
on this interface which is counted by
dot12InHighPriorityFrames.
dot12InHighPriorityOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた高い優先権フレームに含まれた八重奏の数のカウントです」。 このカウンタはOctetCountによってdot12InHighPriorityFramesによって数えられるこのインタフェースに受け取られた各フレームに増加されます。
Note that this counter will roll over very
quickly. It is provided for backward
compatibility for Network Management protocols
that do not support 64 bit counters (e.g. SNMP
version 1)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsReceived."
::= { dot12StatEntry 2 }
このカウンタが非常にすぐにひっくり返ることに注意してください。 「64ビットがカウンタであるとサポートしないNetwork Managementプロトコルのために後方の互換性にそれを提供します(例えば、SNMPバージョン1)。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityOctetsReceived、」 ::= dot12StatEntry2
dot12InNormPriorityFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of normal priority frames
that have been received on this interface.
Includes both good and bad normal priority
frames, as well as normal priority training
frames and normal priority frames which were
priority promoted."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityFramesReceived."
::= { dot12StatEntry 3 }
dot12InNormPriorityFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた正常な優先権フレームのカウントです」。 「善悪の正常な優先権フレームと正常な優先権トレーニングフレームと促進された優先権であった正常な優先権フレームの両方を含んでいます。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aNormalPriorityFramesReceived、」 ::= dot12StatEntry3
dot12InNormPriorityOctets OBJECT-TYPE
SYNTAX Counter32
dot12InNormPriorityOctetsオブジェクト・タイプ構文Counter32
Flick Standards Track [Page 23] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[23ページ]RFC2020IEEE802.12を軽打してください。
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of octets
contained in normal priority frames that have
been received on this interface. This counter is
incremented by OctetCount for each frame received
on this interface which is counted by
dot12InNormPriorityFrames.
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた正常な優先権フレームに含まれた八重奏の数のカウントです」。 このカウンタはOctetCountによってdot12InNormPriorityFramesによって数えられるこのインタフェースに受け取られた各フレームに増加されます。
Note that this counter will roll over very
quickly. It is provided for backward
compatibility for Network Management protocols
that do not support 64 bit counters (e.g. SNMP
version 1)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityOctetsReceived."
::= { dot12StatEntry 4 }
このカウンタが非常にすぐにひっくり返ることに注意してください。 「64ビットがカウンタであるとサポートしないNetwork Managementプロトコルのために後方の互換性にそれを提供します(例えば、SNMPバージョン1)。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aNormalPriorityOctetsReceived、」 ::= dot12StatEntry4
dot12InIPMErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of frames
that have been received on this interface with an
invalid packet marker and no PMI errors. A
repeater will write an invalid packet marker to
the end of a frame containing errors as it is
forwarded through the repeater to the other
ports. This counter is incremented by one for
each frame received on this interface which has
had an invalid packet marker added to the end of
the frame."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aIPMFramesReceived."
::= { dot12StatEntry 5 }
dot12InIPMErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このインタフェースに無効のパケットマーカーで受け取られたフレームの数のカウントにもかかわらず、これが、反対するPMI誤りではありません」。 リピータは無効のパケットマーカーをリピータを通して他のポートにそれを送るので誤りを含むフレームの端まで書くでしょう。 「このカウンタは無効のパケットマーカーをフレームの端に加えたこのインタフェースに受け取られた各フレームあたり1つ増加されます。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aIPMFramesReceived、」 ::= dot12StatEntry5
dot12InOversizeFrameErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of oversize frames
received on this interface. This counter is
incremented by one for each frame received on
dot12InOversizeFrameErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた特大のフレームのカウントです」。 このカウンタは受け取られた各フレームあたり1つ増加されます。
Flick Standards Track [Page 24] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[24ページ]RFC2020IEEE802.12を軽打してください。
this interface whose OctetCount is larger than
the maximum legal frame size. The frame size
which causes this counter to increment is
dependent on the current framing type."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aOversizeFramesReceived."
::= { dot12StatEntry 6 }
OctetCountが最大の法的なフレーム・サイズより大きいこのインタフェース。 「増分へのこのカウンタを引き起こすフレーム・サイズは現在の縁どりタイプに依存しています。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aOversizeFramesReceived、」 ::= dot12StatEntry6
dot12InDataErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of errored frames
received on this interface. This counter is
incremented by one for each frame received on
this interface with any of the following errors:
bad FCS (with no IPM), PMI errors (excluding
frames with an IPM as the only PMI error),
undersize, bad start of frame delimiter, or bad
end of packet marker. Does not include frames
counted by dot12InIPMErrors,
dot12InNullAddressedFrames, or
dot12InOversizeFrameErrors.
dot12InDataErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られたerroredフレームのカウントです」。 このカウンタは以下の誤りのどれかとのこのインタフェースに受け取られた各フレームあたり1つ増加されます: 悪いFCS(IPMのない)、PMI誤り(IPMと共に唯一のPMI誤りとしてフレームを除く)、アンダサイズ、フレームデリミタ、またはパケットマーカーの悪い端の悪い始まり。 dot12InIPMErrors、dot12InNullAddressedFrames、またはdot12InOversizeFrameErrorsによって数えられたフレームを含んでいません。
This counter indicates problems with the cable
directly attached to this interface, while
dot12InIPMErrors indicates problems with remote
cables."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDataErrorFramesReceived."
::= { dot12StatEntry 7 }
「このカウンタは直接このインタフェースに取り付けられるケーブルに関する問題を示しますが、dot12InIPMErrorsはリモートケーブルに関する問題を示します。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aDataErrorFramesReceived、」 ::= dot12StatEntry7
dot12InNullAddressedFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of null addressed frames
received on this interface. This counter is
incremented by one for each frame received on
this interface with a destination MAC address
consisting of all zero bits. Both void and
training frames are included in this counter.
dot12InNullAddressedFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られたフレームであると扱われたヌルのカウントです」。 送付先MACアドレスがすべてのゼロ・ビットから成っていて、このカウンタはこのインタフェースに受け取られた各フレームあたり1つ増加されます。 空間とトレーニングフレームの両方がこのカウンタに含まれています。
Note that since this station would normally not
通常、このステーションは注意するでしょう、したがって、それに注意してください。
Flick Standards Track [Page 25] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[25ページ]RFC2020IEEE802.12を軽打してください。
receive null addressed frames, this counter is
only incremented when this station is operating
in promiscuous mode or in training."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNullAddressedFramesReceived."
::= { dot12StatEntry 8 }
「フレームであると扱われたヌルを受け取ってください、そして、このステーションが無差別なモードかトレーニングで作動しているときだけ、このカウンタは増加されます。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aNullAddressedFramesReceived、」 ::= dot12StatEntry8
dot12OutHighPriorityFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This counter is incremented by one for each high
priority frame successfully transmitted out this
interface."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityFramesTransmitted."
::= { dot12StatEntry 9 }
dot12OutHighPriorityFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このカウンタはこのインタフェースから首尾よく伝えられたそれぞれの高い優先権フレームあたり1つ増加されます」。 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityFramesTransmitted、」 ::= dot12StatEntry9
dot12OutHighPriorityOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This counter is incremented by OctetCount for
each frame counted by dot12OutHighPriorityFrames.
dot12OutHighPriorityOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このカウンタはOctetCountによってdot12OutHighPriorityFramesによって数えられた各フレームに増加されます」。
Note that this counter will roll over very
quickly. It is provided for backward
compatibility for Network Management protocols
that do not support 64 bit counters (e.g. SNMP
version 1)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsTransmitted."
::= { dot12StatEntry 10 }
このカウンタが非常にすぐにひっくり返ることに注意してください。 「64ビットがカウンタであるとサポートしないNetwork Managementプロトコルのために後方の互換性にそれを提供します(例えば、SNMPバージョン1)。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityOctetsTransmitted、」 ::= dot12StatEntry10
dot12TransitionIntoTrainings OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of times
this interface has entered the training state.
This counter is incremented by one each time
dot12Status transitions to 'linkFailure' from any
dot12TransitionIntoTrainings OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースがトレーニング状態に入ったという回の数のカウントです」。 dot12Statusがいずれからも'linkFailure'に移行するたびにこのカウンタは1つ増加されます。
Flick Standards Track [Page 26] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[26ページ]RFC2020IEEE802.12を軽打してください。
state other than 'opening' or 'openFailure'."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aTransitionsIntoTraining."
::= { dot12StatEntry 11 }
「'始まりを除いて、''openFailure'を述べてください。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aTransitionsIntoTraining、」 ::= dot12StatEntry11
dot12HCInHighPriorityOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of octets
contained in high priority frames that have been
received on this interface. This counter is
incremented by OctetCount for each frame received
on this interface which is counted by
dot12InHighPriorityFrames.
dot12HCInHighPriorityOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた高い優先権フレームに含まれた八重奏の数のカウントです」。 このカウンタはOctetCountによってdot12InHighPriorityFramesによって数えられるこのインタフェースに受け取られた各フレームに増加されます。
This counter is a 64 bit version of
dot12InHighPriorityOctets. It should be used by
Network Management protocols which support 64 bit
counters (e.g. SNMPv2)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsReceived."
::= { dot12StatEntry 12 }
このカウンタはdot12InHighPriorityOctetsの64ビットのバージョンです。 「それは64ビットがカウンタ(例えば、SNMPv2)であるとサポートするNetwork Managementプロトコルによって使用されるべきです。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityOctetsReceived、」 ::= dot12StatEntry12
dot12HCInNormPriorityOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a count of the number of octets
contained in normal priority frames that have
been received on this interface. This counter is
incremented by OctetCount for each frame received
on this interface which is counted by
dot12InNormPriorityFrames.
dot12HCInNormPriorityOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「これが、反対するこのインタフェースに受け取られた正常な優先権フレームに含まれた八重奏の数のカウントです」。 このカウンタはOctetCountによってdot12InNormPriorityFramesによって数えられるこのインタフェースに受け取られた各フレームに増加されます。
This counter is a 64 bit version of
dot12InNormPriorityOctets. It should be used by
Network Management protocols which support 64 bit
counters (e.g. SNMPv2)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityOctetsReceived."
::= { dot12StatEntry 13 }
このカウンタはdot12InNormPriorityOctetsの64ビットのバージョンです。 「それは64ビットがカウンタ(例えば、SNMPv2)であるとサポートするNetwork Managementプロトコルによって使用されるべきです。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aNormalPriorityOctetsReceived、」 ::= dot12StatEntry13
Flick Standards Track [Page 27] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[27ページ]RFC2020IEEE802.12を軽打してください。
dot12HCOutHighPriorityOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This counter is incremented by OctetCount for
each frame counted by dot12OutHighPriorityFrames.
dot12HCOutHighPriorityOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このカウンタはOctetCountによってdot12OutHighPriorityFramesによって数えられた各フレームに増加されます」。
This counter is a 64 bit version of
dot12OutHighPriorityOctets. It should be used by
Network Management protocols which support 64 bit
counters (e.g. SNMPv2)."
REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsTransmitted."
::= { dot12StatEntry 14 }
このカウンタはdot12OutHighPriorityOctetsの64ビットのバージョンです。 「それは64ビットがカウンタ(例えば、SNMPv2)であるとサポートするNetwork Managementプロトコルによって使用されるべきです。」 参照、「IEEE標準の802.12-1995 13.2 .5 .2 .1、aHighPriorityOctetsTransmitted、」 ::= dot12StatEntry14
-- conformance information
-- 順応情報
dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 }
dot12Conformanceオブジェクト識別子:、:= dot12MIB2
dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 }
dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 }
dot12Compliancesオブジェクト識別子:、:= dot12Conformance1dot12Groupsオブジェクト識別子:、:= dot12Conformance2
-- compliance statements
-- 承諾声明
dot12Compliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for managed network
entities that have 802.12 interfaces."
dot12Compliance MODULE-COMPLIANCE STATUSの現在の記述、「802.12を持っている管理されたネットワーク実体のための承諾声明は連結します」。
MODULE -- this module
MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup }
MODULE--このモジュールMANDATORY-GROUPSdot12ConfigGroup、dot12StatsGroup
OBJECT dot12DesiredFramingType
MIN-ACCESS read-only
DESCRIPTION
"Write access to this object is not required."
OBJECT dot12DesiredFramingType MIN-ACCESS書き込み禁止記述、「書く、このオブジェクトへのアクセスは必要でない、」
OBJECT dot12DesiredPromiscStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access to this object is not required."
OBJECT dot12DesiredPromiscStatus MIN-ACCESS書き込み禁止記述、「書く、このオブジェクトへのアクセスは必要でない、」
OBJECT dot12Commands
MIN-ACCESS read-only
DESCRIPTION
OBJECT dot12Commands MIN-ACCESS書き込み禁止記述
Flick Standards Track [Page 28] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[28ページ]RFC2020IEEE802.12を軽打してください。
"Write access to this object is not required."
「書く、このオブジェクトへのアクセスは必要でない、」
OBJECT dot12ControlMode
MIN-ACCESS read-only
DESCRIPTION
"Write access to this object is not required."
::= { dot12Compliances 1 }
OBJECT dot12ControlMode MIN-ACCESS書き込み禁止記述、「書く、このオブジェクトへのアクセスは必要でない、」 ::= dot12Compliances1
-- units of conformance
-- ユニットの順応
dot12ConfigGroup OBJECT-GROUP
OBJECTS { dot12DesiredFramingType,
dot12FramingCapability,
dot12DesiredPromiscStatus,
dot12TrainingVersion,
dot12LastTrainingConfig,
dot12Commands, dot12Status,
dot12CurrentFramingType,
dot12ControlMode }
STATUS current
DESCRIPTION
"A collection of objects for managing the status
and configuration of IEEE 802.12 interfaces."
::= { dot12Groups 1 }
dot12ConfigGroup OBJECT-GROUP OBJECTS、dot12DesiredFramingType、dot12FramingCapability、dot12DesiredPromiscStatus、dot12TrainingVersion、dot12LastTrainingConfig、dot12Commands、dot12Status、dot12CurrentFramingType、dot12ControlMode、「IEEE802.12の状態と構成を管理するためのオブジェクトのA収集は連結する」STATUSの現在の記述。 ::= dot12Groups1
dot12StatsGroup OBJECT-GROUP
OBJECTS { dot12InHighPriorityFrames,
dot12InHighPriorityOctets,
dot12InNormPriorityFrames,
dot12InNormPriorityOctets,
dot12InIPMErrors,
dot12InOversizeFrameErrors,
dot12InDataErrors,
dot12InNullAddressedFrames,
dot12OutHighPriorityFrames,
dot12OutHighPriorityOctets,
dot12TransitionIntoTrainings,
dot12HCInHighPriorityOctets,
dot12HCInNormPriorityOctets,
dot12HCOutHighPriorityOctets }
STATUS current
DESCRIPTION
"A collection of objects providing statistics for
IEEE 802.12 interfaces."
::= { dot12Groups 2 }
dot12StatsGroupオブジェクト群対象、dot12InHighPriorityFrames、dot12InHighPriorityOctets、dot12InNormPriorityFrames、dot12InNormPriorityOctets、dot12InIPMErrors、dot12InOversizeFrameErrors、dot12InDataErrors、dot12InNullAddressedFrames、dot12OutHighPriorityFrames、dot12OutHighPriorityOctets、dot12TransitionIntoTrainings、dot12HCInHighPriorityOctets、dot12HCInNormPriorityOctets、dot12HCOutHighPriorityOctets; 「オブジェクトがIEEE802.12に統計を供給する収集は連結する」STATUSの現在の記述。 ::= dot12Groups2
END
終わり
Flick Standards Track [Page 29] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[29ページ]RFC2020IEEE802.12を軽打してください。
5. Acknowledgements
5. 承認
This document was produced by the IETF 100VG-AnyLAN Working Group. It is based on the work of IEEE 802.12.
このドキュメントはIETF 100VG-AnyLAN作業部会によって製作されました。 それはIEEE802.12の仕事に基づいています。
6. References
6. 参照
[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824 (December, 1987).
[1] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824(1987年12月)。
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
SNMP Research, Inc., Cisco Systems, Inc., Dover Beach
Consulting, Inc., International Network Services, January 1996.
[2]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902、SNMPはInc.について研究します、シスコシステムズInc.、ドーヴァービーチコンサルティングInc.、国際ネットワークサービス、1996年1月。
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[3]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、SNMP研究Inc.、シスコシステムズInc.、ドーヴァービーチコンサルティングInc.、国際ネットワークサービス、1996年1月。
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP
Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
[4]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための順応声明は(SNMPv2)について議定書の中で述べます」、RFC1904、SNMP研究Inc.、シスコシステムズInc.、ドーヴァービーチコンサルティングInc.、国際ネットワークサービス、1996年1月。
[5] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[5]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地--、MIB-II、」、STD17、RFC1213、ヒューズLAN Systems国際パフォーマンスSystems、3月1991日
[6] IEEE, "Demand Priority Access Method, Physical Layer and
Repeater Specifications for 100 Mb/s Operation", IEEE Standard
802.12-1995"
「[6] IEEE、802.12-1995にIEEE標準で「100Mb/sの操作のための優先権アクセス法、物理的な層、およびリピータ仕様を要求する」、」
[7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces
Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
January 1994.
[7] McCloghrie、K.、およびKastenholz、F.、「MIB-IIのインタフェースグループの発展」、RFC1573、ヒューズLANシステム、FTPソフトウェア(1994年1月)。
[8] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software,
Inc., July, 1994.
[8] Kastenholz、F.、「イーサネットのよう管理オブジェクトの定義はタイプを連結します」、STD50、RFC1643、FTPソフトウェアInc.、1994年7月。
Flick Standards Track [Page 30] RFC 2020 IEEE 802.12 Interface MIB October 1996
インタフェースMIB1996年10月に標準化過程[30ページ]RFC2020IEEE802.12を軽打してください。
[9] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types using SMIv2", RFC 1650, FTP
Software, Inc., August, 1994.
[9] Kastenholz、F.、「SMIv2"を使用して、イーサネットのよう管理オブジェクトの定義はタイプを連結します、RFC1650、FTPソフトウェアInc.、1994年8月。」
[10] McCloghrie, K., and Decker, E., "IEEE 802.5 MIB using SMIv2",
RFC 1748, Cisco Systems, Inc., December, 1994.
[10] McCloghrie、K.とデッカー、E.、「SMIv2"、RFC1748、シスコシステムズInc.を使用するIEEE802.5MIB、1994年12月。」
[11] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station
Source Routing MIB using SMIv2", RFC 1749, Cisco Systems, Inc.,
December, 1994.
[11]McCloghrieとK.とベイカー、F.とデッカー、E.、「SMIv2"、RFC1749、シスコシステムズInc.を使用しているIEEE802.5駅のソースルート設定MIB、1994年12月。」
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Author's Address
8. 作者のアドレス
John Flick Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556
ジョン軽打ヒューレットパッカード会社8000山麓の丘Blvd. S5556ローズビル、M/カリフォルニア95747-5556
Phone: +1 916 785 4018 Email: johnf@hprnd.rose.hp.com
以下に電話をしてください。 +1 4018年の916 785メール: johnf@hprnd.rose.hp.com
Flick Standards Track [Page 31]
軽打標準化過程[31ページ]
一覧
スポンサーリンク
