RFC1368 日本語訳
1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D.McMaster, K. McCloghrie. October 1992. (Format: TXT=83905 bytes) (Obsoleted by RFC1516) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. McMaster
Request for Comments: 1368 SynOptics Communications, Inc.
K. McCloghrie
Hughes LAN Systems, Inc.
October 1992
コメントを求めるワーキンググループD.マクマスターの要求をネットワークでつないでください: 1368年のSynOpticsコミュニケーションInc.K.McCloghrieヒューズLANシステムInc.1992年10月
Definitions of Managed Objects for IEEE 802.3 Repeater Devices
IEEE802.3リピータ装置のための管理オブジェクトの定義
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
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 IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs."
このメモは使用のために、ネットワーク管理プロトコルでTCP/IPベースのインターネットでManagement Information基地の一部(MIB)を定義します。 特に、それは時々「ハブ」と呼ばれたMb/第2管理IEEE802.3 10ベースバンドリピータのために物を定義します。
Table of Contents
目次
1. Management Framework ........................................ 2 2. Objects ..................................................... 2 2.1 Format of Definitions ...................................... 3 3. Overview .................................................... 3 3.1 Terminology ................................................ 3 3.1.1 Repeaters, Hubs and Concentrators ........................ 3 3.1.2 Repeaters, Ports, and MAUs ............................... 4 3.1.3 Ports and Groups ......................................... 6 3.2 Supporting Functions ....................................... 7 3.3 Structure of MIB ........................................... 9 3.3.1 The Basic Group Definitions .............................. 10 3.3.2 The Monitor Group Definitions ............................ 10 3.3.3 The Address Tracking Group Definitions ................... 10 3.4 Relationship to Other MIBs ................................. 10 3.4.1 Relationship to the 'system' group ....................... 10 3.4.2 Relationship to the 'interfaces' group .................... 10 3.5 Textual Conventions ........................................ 11 4. Definitions ................................................. 11 4.1 MIB Groups in the Repeater MIB ............................. 12 4.2 The Basic Group Definitions ................................ 13 4.3 The Monitor Group Definitions .............................. 23 4.4 The Address Tracking Group Definitions ..................... 33
1. 管理枠組み… 2 2. 物… 2 2.1 定義の形式… 3 3. 概観… 3 3.1用語… 3 3.1 .1個のリピータ、ハブ、および集中装置… 3 3.1 .2リピータ、ポート、およびMAUs… 4 3.1 .3 移植して、分類します。 6 3.2 支持は機能します… 7 3.3 MIBの構造… 9 3.3 .1 基本的なグループ定義… 10 3.3 .2 モニターグループ定義… 10 3.3 .3 アドレスの追跡グループ定義… 10 他のMIBsとの3.4関係… 10 3.4 .1 'システム'との関係は分類されます… 10 3.4 .2 'インタフェース'との関係は分類されます… 10 3.5 原文のコンベンション… 11 4. 定義… 11 4.1 MIBはリピータMIBで分類します… 12 4.2 基本的なグループ定義… 13 4.3 モニターグループ定義… 23 4.4 アドレスの追跡グループ定義… 33
McMaster & McCloghrie [Page 1] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[1ページ]RFC1368 802.3リピータMIB1992年10月
4.5 Traps for use by Repeaters ................................. 35 5. Acknowledgments ............................................. 37 6. References .................................................. 39 7. Security Considerations...................................... 40 8. Authors' Addresses........................................... 40
4.5 Repeatersによる使用のために、捕らえます… 35 5. 承認… 37 6. 参照… 39 7. セキュリティ問題… 40 8. 作者のアドレス… 40
1. Management Framework
1. 管理枠組み
The Internet-standard Network Management Framework consists of three components. They are:
インターネット標準Network Management Frameworkは3つのコンポーネントから成ります。 それらは以下の通りです。
STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. STD
16/RFC 1212 [7] defines a more concise description mechanism,
which is wholly consistent with the SMI.
SMIを定義するSTD16/RFC1155[1]、メカニズムは説明と命名に管理の目的のための物を使用しました。 STD16/RFC1212[7]は、より簡潔な記述メカニズムを定義します。(それは、完全にSMIと一致しています)。
RFC 1156 [2] which defines MIB-I, the core set of managed objects
for the Internet suite of protocols. STD 17/RFC 1213 [4] defines
MIB-II, an evolution of MIB-I based on implementation experience
and new operational requirements.
MIB-I、管理オブジェクトの巻き癖をプロトコルのインターネットスイートと定義するRFC1156[2]。 STD17/RFC1213[4]はMIB-II、実現経験と新しい操作上の要件に基づくMIB-Iの発展を定義します。
STD 15/RFC 1157 [3] which defines the SNMP, the protocol used for
network access to managed objects.
SNMP、管理オブジェクトへのネットワークアクセスに使用されるプロトコルを定義するSTD15/RFC1157[3]。
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
Frameworkは、新しい物が実験と評価の目的のために定義されるのを可能にします。
2. Objects
2. 物
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [5] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBの物は、SMIで定義された抽象的なSyntax Notation One(ASN.1)[5]の部分集合を使用することで定義されます。 各物には、特に、名前、構文、およびコード化があります。 名前は物の識別子、オブジェクト・タイプを指定する行政上割り当てられた名前です。 物の例に伴うオブジェクト・タイプは、唯一物の特定の具体化を特定するのに勤めます。 OBJECT DESCRIPTORは、人間の便宜に、私たちがしばしば原文のストリングを使用すると呼んで、また、物を示すのはタイプされます。
The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [1] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity.
オブジェクト・タイプの構文はそのオブジェクト・タイプにとって、対応する抽象的なデータ構造を定義します。 ASN.1言語はこのために使用されます。 しかしながら、SMI[1]はわざわざ使用されるかもしれないASN.1構造物を制限します。 簡単さのために明らかにこれらの制限をします。
The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the
オブジェクト・タイプのコード化は単にそのオブジェクト・タイプがオブジェクト・タイプの構文を使用することでどう代理をされるかということです。 それとなく、つながります。
McMaster & McCloghrie [Page 2] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[2ページ]RFC1368 802.3リピータMIB1992年10月
notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network.
オブジェクト・タイプの構文とコード化の概念はネットワークで伝えられるとオブジェクト・タイプがどう代理をされるかということです。
The SMI specifies the use of the basic encoding rules of ASN.1 [6], subject to the additional requirements imposed by the SNMP.
SMIはSNMPによって課された追加要件を条件としてASN.1[6]の基本的な符号化規則の使用を指定します。
2.1. Format of Definitions
2.1. 定義の形式
Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [7,8].
セクション4はこのMIBモジュールで含まれたすべてのオブジェクト・タイプの仕様を含みます。 オブジェクト・タイプは、[7、8]で指定された拡大で修正されるようにSMIで定義されたコンベンションを使用することで定義されます。
3. Overview
3. 概観
Instances of the object types defined in this memo represent attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE 802.3/ISO 8802-3 CSMA/CD standard [9].
このメモで定義されたオブジェクト・タイプの例はIEEE802.3の(イーサネットのよう)のリピータの属性を表します、セクション9、IEEE802.3/ISO8802-3CSMA/CD規格[9]における「10Mb/sのベースバンドネットワークのためのリピータユニット」によって定義されるように。
These Repeater MIB objects may be used to manage non-standard repeater-like devices, but defining objects to describe implementation-specific properties of non-standard repeater-like devices is outside the scope of this memo.
これらのRepeater MIB物は標準的でないリピータのような装置を管理するのに使用されるかもしれませんが、このメモの範囲の外に標準的でないリピータのような装置の実現特有の性質について説明するために物を定義するのがあります。
The definitions presented here are based on the IEEE draft standard P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters." [10] Implementors of these MIB objects should note that [10] explicitly describes when, where, and how various repeater attributes are measured. The IEEE document also describes the effects of repeater actions that may be invoked by manipulating instances of the MIB objects defined here.
IEEE草稿の標準のP802.3K、「10Mb/sのベースバンドリピータのための層の管理」にここに提示された定義は基づいています。 [10] これらのMIB物の作成者は、[10]が明らかにいつ、どこと様々なリピータ属性がどう測定されるかを説明することに注意するべきです。 また、IEEEドキュメントはここで定義されたMIB物の例を操ることによって呼び出されるかもしれないリピータ動作の効果について説明します。
The counters in this document are defined to be the same as those counters in the IEEE 802.3 Repeater Management draft, with the intention that a single instrumentation can be used to implement both the IEEE and IETF management standards.
カウンタはIEEE802.3Repeater Management草稿でそれらのカウンタと同じになるように本書では定義されます、IEEEとIETF管理規格の両方を実行するのにただ一つの計装を使用できるという意志で。
3.1. Terminology
3.1. 用語
3.1.1. Repeaters, Hubs and Concentrators
3.1.1. リピータ、ハブ、および集中装置
In late 1988, the IEEE 802.3 Hub Management task force was chartered to define managed objects for both 802.3 repeaters and the proposed 10BASE-FA synchronous active stars. The term "hub" was used to cover both repeaters and active stars.
1988年後半に、IEEE802.3Hub Management特別委員会は、802.3のリピータと提案された10BASE-FA同期活発な星の両方のために管理オブジェクトを定義するためにチャーターされました。 「ハブ」という用語は、リピータと活発な星の両方を覆うのに使用されました。
In March, 1991, the active star proposal was dropped from the 10BASE-F draft. Subsequently the 802.3 group changed the name of the
1991年3月に、活発な星の提案は10BASE-F草稿から落とされました。 次に802.3グループは改称しました。
McMaster & McCloghrie [Page 3] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[3ページ]RFC1368 802.3リピータMIB1992年10月
task force to be the IEEE 802.3 Repeater Management Task Force, and likewise renamed their draft.
同様にIEEE802.3Repeater Management Task Forceである特別委員会は彼らの草稿を改名しました。
The use of the term "hub" has led to some confusion, as the terms "hub," "intelligent hub," and "concentrator" are often used to indicate a modular chassis with plug-in modules that provide generalized LAN/WAN connectivity, often with a mix of 802.3 repeater, token ring, and FDDI connectivity, internetworked by bridges, routers, and terminal servers.
「ハブ」という用語の使用は何らかの混乱につながりました、提供されるプラグイン・モジュールがあるモジュールの車台がLAN/WANの接続性を広めたのを示すのにおいて「ハブ」という期間、「インテリジェントハブ」、および「集中装置」がしばしば使用されているとき、しばしば橋によってinternetworkedされた802.3のリピータ、トークンリング、およびFDDIの接続性のミックス、ルータ、および端末のサーバで。
To be clear that this work covers the management of IEEE 802.3 repeaters only, the editors of this MIB definitions document chose to call this a "Repeater MIB" instead of a "Hub MIB."
この仕事がIEEE802.3の管理をカバーするのが明確に、なるように、リピータ専用であり、このMIB定義ドキュメントのエディタは、「ハブMIB」の代わりにこの「リピータMIB」と呼ぶのを選びました。
3.1.2. Repeaters, Ports, and MAUs
3.1.2. リピータ、ポート、およびMAUs
The following text roughly defines the terms "repeater," "port," and "MAU" as used in the context of this memo. This text is imprecise and omits many technical details. For a more complete and precise definition of these terms, refer to Section 9 of [9].
以下のテキストはおよそこのメモの文脈で使用される用語「リピータ」、「ポート」、および「マウ」を定義します。 本稿は、不正確であり、多くの技術的詳細を省略します。 これらの用語の、より完全で正確な定義について、[9]のセクション9を参照してください。
An IEEE 802.3 repeater connects "Ethernet-like" media segments together to extend the network length and topology beyond what can be achieved with a single coax segment. It can be pictured as a star structure with two or more input/output ports. The diagram below illustrates a 6-port repeater:
IEEE802.3リピータはネットワークの長さを広げるために「イーサネットのような」メディアセグメントを一緒に接続します、そして、シングルで達成できることを超えたトポロジーはセグメントをおだてます。 2つ以上の入力/出力ポートがある星の構造としてそれについて描写できます。 以下のダイヤグラムは6ポートのリピータを例証します:
^ ^
| |
\ \ / /
\ \ / /
_____\ v /_____
-> ______ ______ ->
/ ^ \
/ / \ \
/ / \ \
| |
v v
^ ^ | | \ \ / / \ \ / / _____\対/_____ ->。______ ______ ->/^ \//\\//\\| | vに対して
Figure 1. Repeater Unit
図1。 リピータユニット
All the stations on the media segments connected to a given repeater's ports participate in a single collision domain. A packet transmitted by any of these stations is seen by all of these stations.
与えられたリピータのポートに接続されたメディアセグメントのすべてのステーションが単一のコリジョンドメインに参加します。 これらのステーションのいずれによっても送信されたパケットはこれらのステーションのすべてによって見られます。
Data coming in on any port in the repeater is transmitted out through
リピータのどんなポートにも参加するデータが通じて外に送られます。
McMaster & McCloghrie [Page 4] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[4ページ]RFC1368 802.3リピータMIB1992年10月
each of the remaining n-1 ports. If data comes in to the repeater on two or more ports simultaneously or the repeater detects a collision on the incoming port, the repeater transmits a jamming signal out on all ports for the duration of the collision.
それぞれの残っているn-1ポート。 同時に、2つ以上のポートの上のリピータにデータを入らせるか、またはリピータが入って来るポートの上に衝突を検出するなら、リピータは衝突の持続時間のためにすべてのポートの外にジャム信号を送信します。
A repeater is a bit-wise store-and-forward device. It is differentiated from a bridge (a frame store-and-forward device) in that it is primarily concerned with carrier sense and data bits, and does not make data-handling decisions based on the legality or contents of a packet. A repeater retransmits data bits as they are received. Its data FIFO holds only enough bits to make sure that the FIFO does not underflow when the data rate of incoming bits is slightly slower than the repeater's transmission rate.
リピータは少し的な店とフォワード装置です。 それは、主としてキャリア検知とデータ・ビットに関係があって、データハンドリングをパケットの合法かコンテンツに基づく決定にしないので、橋(フレーム店とフォワード装置)と区別されます。 それらが受け取られているとき、リピータはデータ・ビットを再送します。 データ先入れ先出し法が確実にすることができるくらいの何ビットだけも成立するので、入って来るビットのデータ信号速度がリピータの通信速度よりわずかに遅いときに、先入れ先出し法はどんなアンダーフローもしません。
A repeater is not an end-station on the network, and does not count toward the overall limit of 1024 stations. A repeater has no MAC address associated with it, and therefore packets may not be addressed to the repeater or to its ports. (Packets may be addressed to the MAC address of a management entity that is monitoring a repeater. This management entity may or may not be connected to the network through one of the repeater's ports. How the management entity obtains information about the activity on the repeater is an implementation issue, and is not discussed in this memo.)
リピータは、ネットワークの端ステーションでなく、また1024のステーションの総合的な限界に向かって数えられません。 リピータには、それに関連しているどんなMACアドレスもありません、そして、したがって、パケットはリピータ、または、そのポートに記述されないかもしれません。 (パケットはリピータをモニターしている経営体のMACアドレスに記述されるかもしれません。 この経営体はリピータのポートの1つを通してネットワークに関連づけられるかもしれません。 経営体がリピータの上でどう活動の情報を得るかについて、導入問題であり、このメモで議論しません。)
A repeater is connected to the network with Medium Attachment Units
(MAUs), and sometimes through Attachment Unit Interfaces (AUIs) as
well. ("MAUs" are also known as transceivers, and an "AUI" is the
same as a 15-pin Ethernet or DIX connector.)
リピータはMedium Attachment Units(MAUs)と、時々また、Attachment Unit Interfaces(AUIs)を通してネットワークに接続されます。 (また、「MAUs」はトランシーバーとして知られていて、"AUI"は15ピンのイーサネットかディックスコネクタと同じです。)
The 802.3 standard defines a "repeater set" as the "repeater unit" plus its associated MAUs (and AUIs if present). The "repeater unit" is defined as the portion of the repeater set that is inboard of the physical media interfaces. The MAUs may be physically separate from the repeater unit, or they may be integrated into the same physical package.
802.3規格が「リピータユニット」とその関連MAUsと「リピータセット」を定義する、(AUIs、プレゼント) 「リピータユニット」は内側に物理的なメディアインタフェースのものであるリピータセットの一部と定義されます。 MAUsがリピータユニットから肉体的に別々であるかもしれませんか、または彼らは同じ物理的なパッケージと統合されるかもしれません。
(MAU) (MAU)
\ \ / /
\ \ / /
_____\ v /_____
(MAU) ______ ______ (MAU)
/ ^ \
/ / \ \
/ / \ \
(MAU) (MAU)
(マウ)(マウ)\\//\\//_____\対/_____ (マウ) ______ ______ (マウ) /^ \//\\//\\(マウ)(マウ)
Figure 2. Repeater Set
図2。 リピータセット
McMaster & McCloghrie [Page 5] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[5ページ]RFC1368 802.3リピータMIB1992年10月
The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow" coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted- pair), and FOIRL (asynchronous fiber optic inter-repeater link, which is being combined into the 10BASE-F standard as 10BASE-FL). The draft 10BASE-F standard also includes the definition for a new synchronous fiber optic attachment, known as 10BASE-FB.
最も多くの一般的に使用されたMAUsが10BASE-5(「黄色」がおだてる太い部分へのAUI)です、10BASE-2、(薄くなるBNC、おだて、)、10BASE-T(撚り合わせている組を非保護した)、およびFOIRL(非同期な光ファイバー相互リピータリンク)。(リンクは10BASE-フロリダとして10BASE-F規格に結合されています)。 また、草稿10BASE-F規格は10BASE-FBとして知られている新たな同期光ファイバー付属のための定義を含んでいます。
It should be stressed that the repeater MIB being defined by the IEEE covers only the repeater unit management - it does not include management of the MAUs that form the repeater set. The IEEE recognizes that MAU management should be the same for MAUs connected to end-stations (DTEs) as it is for MAUs connected to repeaters. This memo follows the same strategy; the definition of management information for MAUs is being addressed in a separate memo.
IEEEによって定義されるリピータMIBがリピータユニット管理だけをカバーすると強調されるべきです--それはリピータセットを形成するMAUsの管理を含んでいません。 IEEEは、それがリピータに接続されたMAUsのためのものであるので端ステーション(DTEs)に接続されたMAUsに、MAU管理が同じであるべきであると認めます。 このメモは同じ戦略に従います。 MAUsのための経営情報の定義は別々のメモに記述されています。
3.1.3. Ports and Groups
3.1.3. ポートとグループ
Repeaters are often implemented in modular "concentrators," where a card cage holds several field-replaceable cards. Several cards may form a single repeater unit, with each card containing one or more of the repeater's ports. Because of this modular architecture, users typically identify these repeater ports with a card number plus the port number relative to the card, e.g., Card 3, Port 11.
リピータはモジュールの「集中装置」でしばしば実行されます。そこでは、カードの檻が数枚の分野取替え可能なカードを支えます。 数枚のカードが各カードがリピータのポートの1つ以上を含んでいる単一のリピータ単位を形成するかもしれません。 このモジュールの構造のために、ユーザはカード、例えば、Card3(Port11)に比例してこれらのリピータポートをカードナンバーとポートナンバーと通常同一視します。
To support this modular numbering scheme, this document follows the example of the IEEE Repeater Management draft [10], allowing an implementor to separate the ports in a repeater into "groups", if desired. For example, an implementor might choose to represent field-replaceable units as groups of ports so that the port numbering would match the modular hardware implementation.
このモジュールのナンバリングスキームを支持するために、このドキュメントはIEEE Repeater Management草稿[10]に関する例に倣っています、作成者がリピータで「グループ」にポートを切り離すのを許容して、望まれているなら。 例えば、作成者は、ポート付番がモジュラーハードウェア実現に合うようにポートのグループとして分野取替え可能なユニットを表すのを選ぶかもしれません。
This group mapping is recommended but optional. An implementor may choose to put all of a modular repeater's ports into a single group, or to divide the ports into groups that do not match physical divisions.
このグループマッピングは、お勧めですが、任意です。 作成者は、モジュールのリピータのポートのすべてをただ一つのグループに入れるか、またはポートを物理的な部門に合っていないグループに分割するのを選ぶかもしれません。
The object rptrGroupCapacity, which has a maximum value of 1024, indicates the maximum number of groups that a given repeater may contain. The value of rptrGroupCapacity must remain constant from one management restart to the next.
物のrptrGroupCapacity(1024年の最大値を持っている)は与えられたリピータが含むかもしれないグループの最大数を示します。 rptrGroupCapacityの値は1つの管理再開から次まで一定のままで残らなければなりません。
Each group within the repeater is uniquely identified by a group number in the range 1..rptrGroupCapacity. Groups may come and go without causing a management reset, and may be sparsely numbered within the repeater. For example, in a 12-card cage, cards 3, 5, 6, and 7 may together form a single repeater, and the implementor may choose to number them as groups 3, 5, 6, and 7, respectively.
リピータの中の各グループは範囲1のグループ番号によって唯一特定されます。rptrGroupCapacity。 グループは、管理リセットを引き起こしながらなしで済ませに来て、リピータの中でまばらに付番されるかもしれません。 例えば、12カードの檻、一緒に3、5、6、および7がそうするカードでは単一のリピータを形成してください。そうすれば、作成者はグループ3、5、6、および7としてそれぞれ数にそれらを選んでもよいです。
McMaster & McCloghrie [Page 6] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[6ページ]RFC1368 802.3リピータMIB1992年10月
The object rptrGroupPortCapacity, which also has a maximum value of 1024, indicates the maximum number of ports that a given group may contain. The value of rptrGroupPortCapacity must not change for a given group. However, a group may be deleted from the repeater and replaced with a group containing a different number of ports. The value of rptrGroupLastOperStatusChange will indicate that a change took place.
物のrptrGroupPortCapacity(また、1024年の最大値を持っている)は与えられたグループが含むかもしれないポートの最大数を示します。 rptrGroupPortCapacityの値は与えられたグループのために変化してはいけません。 しかしながら、グループをリピータから削除して、異なった数のポートを含んでいるグループに取り替えるかもしれません。 rptrGroupLastOperStatusChangeの値は、変化が起こったのを示すでしょう。
Each port within the repeater is uniquely identified by a combination of group number and port number, where port number is an integer in the range 1..rptrGroupPortCapacity. As with groups within a repeater, ports within a group may be sparsely numbered. Likewise, ports may come and go within a group without causing a management reset.
リピータの中の各ポートはグループ番号とポートナンバーの組み合わせで唯一特定されます、ポートナンバーが範囲1の整数であるところで。rptrGroupPortCapacity。 リピータの中にグループがある場合、グループの中のポートはまばらに付番されるかもしれません。 同様に、管理リセットを引き起こさないで、ポートは、グループの中に来て、行くかもしれません。
3.2. Supporting Functions
3.2. 機能をサポートします。
The IEEE 802.3 Hub Management draft [10] defines the following seven functions and seven signals used to describe precisely when port counters are incremented. The relationship between the functions and signals is shown in Figure 3.
IEEE802.3Hub Management草稿[10]は以下の7つの機能を定義します、そして、7つの信号が以前はよくポートカウンタが正確にいつ増加されているかを説明していました。 機能と信号との関係は図3に示されます。
The CollisionEvent, ActivityDuration, CarrierEvent, FramingError, OctetCount, FCSError, and SourceAddress output signals defined here are not retrievable MIB objects, but rather are concepts used in defining the MIB objects. The inputs are defined in Section 9 of the IEEE 802.3 standard [9].
出力信号がここで定義したCollisionEvent、ActivityDuration、CarrierEvent、FramingError、OctetCount、FCSError、およびSourceAddressは回収可能なMIB物ではありませんが、むしろMIB物を定義する際に使用される概念です。 入力はIEEE802.3規格[9]のセクション9で定義されます。
McMaster & McCloghrie [Page 7] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[7ページ]RFC1368 802.3リピータMIB1992年10月
+---------+
|Collision|--------------------->CollisionEvent
CollIn(X)+>|Event |
| |Funct | +--------+
| +---------+ |Activity|
| +-------+ |Timing |->ActivityDuration
+>|Carrier| +---->|Funct |
|Event | | +--------+
DataIn(X)->|Funct |+-----+---------------->CarrierEvent
+-------+|
| +-------+
+>|Framing|------------>FramingError
|Funct | +-------+
decodedData---------->| |+>|Octet |
+-------+| |Count |->OctetCount
| |Funct |
| +-------+
| +-------+
Octet | |Cyclic |
Stream +>|Redund.|
| |Check |->FCSError
| |Funct |
| +-------+
| +-------+
| |Source |
+>|Address|->SourceAddress
|Funct |
+-------+
+---------+ |衝突|--------------------->CollisionEvent CollIn(X)+>|出来事| | |Funct| +--------+ | +---------+ |活動| | +-------+ |タイミング|->ActivityDuration+>|キャリヤー| +---->|Funct| |出来事| | +--------+ DataIn(X)>|Funct|+-----+---------------->CarrierEvent+-------+| | +-------+ +>|縁どり|------------>FramingError|Funct| +-------+ decodedData---------->| |+>|八重奏| +-------+| |カウント|->OctetCount| |Funct| | +-------+ | +-------+ 八重奏| |周期的| 流れ+>|Redund、|| |チェック|->FCSError| |Funct| | +-------+ | +-------+ | |ソース| +>|アドレス|->SourceAddress|Funct| +-------+
Figure 3. Port Functions Relationship
図3。 港湾機能関係
Collision Event Function: The collision event function asserts the CollisionEvent signal when the CollIn(X) variable has the value SQE. The CollisionEvent signal remains asserted until the assertion of any CarrierEvent signal due to the reception of the following event.
衝突イベント機能: CollIn(X)変数に値のSQEがあるとき、衝突イベント機能はCollisionEvent信号について断言します。 CollisionEvent信号は以下の出来事のレセプションのためどんなCarrierEvent信号の主張までも断言されたままで残っています。
Carrier Event Function: The carrier event function asserts the CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2 [9], and the port has been determined to be port N. It deasserts the CarrierEvent signal when, for a duration of at least Carrier Recovery Time (Ref: 9.5.6.5 [9]), both the DataIn(N) variable has the value II and the CollIn(N) variable has the value -SQE. The value N is the port assigned at the time of transition from the IDLE state.
キャリヤーイベント機能: リピータはIDLE状態を出ます、図9-2[9]、ポートがCarrierEventがポートN.It deassertsに、なるようにいつに合図するかと決心しているとき、キャリヤーイベント機能はCarrierEvent信号について断言します、少なくともCarrier Recovery Timeの持続時間のために(審判: 9.5 .6 .5 [9]) 両方のDataIn(N)変数には、値IIがあって、CollIn(N)変数に値の-SQEがあります。 値NはIDLE状態からの変遷時点で割り当てられたポートです。
Framing Function: The framing function recognizes the boundaries of an incoming frame by monitoring the CarrierEvent signal and the decoded data stream. Data bits are accepted while the CarrierEvent
縁どり機能: 縁どり機能は、CarrierEvent信号と解読されたデータ・ストリームをモニターすることによって、入って来るフレームの境界を認識します。 CarrierEventである間、データ・ビットを受け入れます。
McMaster & McCloghrie [Page 8] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[8ページ]RFC1368 802.3リピータMIB1992年10月
signal is asserted. The framing function strips preamble and start of frame delimiter from the received data stream. The remaining bits are aligned along octet boundaries. If there is not an integral number of octets, then FramingError shall be asserted. The FramingError signal is cleared upon the assertion of the CarrierEvent signal due to the reception of the following event.
信号は断言されます。 縁どり機能は受信データストリームから序文と始めからフレームデリミタを奪い取ります。 残っているビットは八重奏境界に沿って並べられます。 整数の八重奏がなければ、FramingErrorは断言されるものとします。 FramingError信号はCarrierEvent信号の主張のときに以下の出来事のレセプションのためきれいにされます。
Activity Timing Function: The activity timing function measures the duration of the assertion of the CarrierEvent signal. This duration value must be adjusted by removing the value of Carrier Recovery Time (Ref: 9.5.6.5 [9]) to obtain the true duration of activity on the network. The output of the Activity Timing function is the ActivityDuration value, which represents the duration of the CarrierEvent signal as expressed in units of bit times.
活動タイミング機能: 活動タイミング機能はCarrierEvent信号の主張の持続時間を測定します。 Carrier Recovery Timeの値を取り除くことによってこの持続時間値を調整しなければならない、(審判: 9.5 .6 .5 ネットワークで活動の本当の持続時間を得る[9])。 Activity Timing機能の出力はActivityDuration値です。(その値はユニットの噛み付いている回で言い表されるようにCarrierEvent信号の持続時間を表します)。
Octet Counting Function: The octet counting function counts the number of complete octets received from the output of the framing function. The output of the octet counting function is the OctetCount value. The OctetCount value is reset to zero upon the assertion of the CarrierEvent signal due to the reception of the following event.
八重奏勘定機能: 八重奏勘定機能は縁どり機能の出力から受けられた完全な八重奏の数を数えます。 八重奏勘定機能の出力はOctetCount値です。 OctetCount値は以下の出来事のレセプションのためCarrierEvent信号の主張のゼロにリセットされます。
Cyclic Redundancy Check Function: The cyclic redundancy check function verifies that the sequence of octets output by the framing function contains a valid frame check sequence field. The frame check sequence field is the last four octets received from the output of the framing function. The algorithm for generating an FCS from the octet stream is specified in 3.2.8 [9]. If the FCS generated according to this algorithm is not the same as the last four octets received from the framing function then the FCSError signal is asserted. The FCSError signal is cleared upon the assertion of the CarrierEvent signal due to the reception of the following event.
周期冗長検査機能: 周期冗長検査機能は、縁どり機能による八重奏出力の系列が有効なフレームチェックシーケンス分野を含むことを確かめます。 フレームチェックシーケンス分野は縁どり機能の出力から受けられた最後の4つの八重奏です。 八重奏の流れからのFCSを発生させるためのアルゴリズムは3.2.8[9]で指定されます。 このアルゴリズムに応じて発生するFCSが最後の4つの八重奏が縁どり機能から受信されたのと同じでないなら、FCSError信号は断言されます。 FCSError信号はCarrierEvent信号の主張のときに以下の出来事のレセプションのためきれいにされます。
Source Address Function: The source address function extracts octets from the stream output by the framing function. The seventh through twelfth octets shall be extracted from the octet stream and output as the SourceAddress variable. The SourceAddress variable is set to an invalid state upon the assertion of the CarrierEvent signal due to the reception of the following event.
ソースアドレス機能: ソースアドレス機能は縁どり機能で流れの出力から八重奏を抽出します。 7番目〜12番目の八重奏はSourceAddress変数として八重奏の流れと出力から抽出されるものとします。 SourceAddress変数は以下の出来事のレセプションによるCarrierEvent信号の主張の無効の状態へのセットです。
3.3. Structure of MIB
3.3. MIBの構造
Objects in this MIB are arranged into MIB groups. Each MIB group is organized as a set of related objects.
このMIBの物はMIBグループにアレンジされます。 それぞれのMIBグループは1セットの関連する物としてまとめられます。
McMaster & McCloghrie [Page 9] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[9ページ]RFC1368 802.3リピータMIB1992年10月
3.3.1. The Basic Group Definitions
3.3.1. 基本的なグループ定義
This mandatory group contains the objects which are applicable to all repeaters. It contains status, parameter and control objects for the repeater as a whole, the port groups within the repeater, as well as for the individual ports themselves.
この義務的なグループはすべてのリピータに適切な物を含みます。 それは全体でリピータのための状態、パラメタ、およびコントロール物を含んでいます、リピータの中のポートグループ、よく個々のポート自体のように。
3.3.2. The Monitor Group Definitions
3.3.2. モニターグループ定義
This optional group contains monitoring statistics for the repeater as a whole and for individual ports.
この任意のグループは全体でリピータと個々のポートへのモニターしている統計を含みます。
3.3.3. The Address Tracking Group Definitions
3.3.3. アドレスの追跡グループ定義
This optional group contains objects for tracking the MAC addresses of the DTEs attached to the ports of the repeater.
この任意のグループはリピータのポートに取り付けられたDTEsのMACアドレスを追跡するための物を含みます。
3.4. Relationship to Other MIBs
3.4. 他のMIBsとの関係
It is assumed that a repeater implementing this MIB will also implement (at least) the 'system' group defined in MIB-II [4].
また、このMIBを実行するリピータがMIB-II[4]で定義された'システム'グループを実行する(少なくとも)と思われます。
3.4.1. Relationship to the 'system' group
3.4.1. 'システム'グループとの関係
In MIB-II, the 'system' group is defined as being mandatory for all systems such that each managed entity contains one instance of each object in the 'system' group. Thus, those objects apply to the entity even if the entity's sole functionality is management of a repeater.
MIB-IIでは、'システム'グループがすべてのシステムに義務的であると定義されるので、それぞれの管理された実体は'システム'グループにそれぞれの物の1つの例を含んでいます。 したがって、それらの物は実体の唯一の機能性がリピータの管理であっても実体に適用されます。
3.4.2. Relationship to the 'interfaces' group
3.4.2. 'インタフェース'グループとの関係
In MIB-II, the 'interfaces' group is defined as being mandatory for all systems and contains information on an entity's interfaces, where each interface is thought of as being attached to a 'subnetwork'. (Note that this term is not to be confused with 'subnet' which refers to an addressing partitioning scheme used in the Internet suite of protocols.)
MIB-IIでは、'インタフェース'グループは、すべてのシステムに義務的であると定義されて、実体のインタフェースの情報を含みます。(そこでは、各インタフェースが'サブネットワーク'に付けられていると考えられます)。 (プロトコルのインターネットスイートで使用されるアドレシング仕切りの計画について言及する'サブネット'に今期を混乱させてはいけないことに注意してください。)
This Repeater MIB uses the notion of ports on a repeater. The concept of a MIB-II interface has NO specific relationship to a repeater's port. Therefore, the 'interfaces' group applies only to the one (or more) network interfaces on which the entity managing the repeater sends and receives management protocol operations, and does not apply to the repeater's ports.
このRepeater MIBはリピータの上のポートの概念を使用します。 MIB-IIインタフェースの概念には、リピータのポートとのどんな特定の関係もありません。 したがって、'インタフェース'グループはリピータを管理する実体が管理プロトコル操作を送って、受けて、リピータのポートに適用されない1つ(さらに)のネットワーク・インターフェースだけに適用されます。
This is consistent with the physical-layer nature of a repeater. A repeater is a bitwise store-and-forward device. It recognizes
これはリピータの物理的な層の自然と一致しています。 リピータによるaが店とフォワード装置をbitwiseするということです。 それは認識します。
McMaster & McCloghrie [Page 10] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[10ページ]RFC1368 802.3リピータMIB1992年10月
activity and bits, but does not process incoming data based on any packet-related information (such as checksum or addresses). A repeater has no MAC address, no MAC implementation, and does not pass packets up to higher-level protocol entities for processing.
そして、活動、どんなパケット関連の情報(チェックサムかアドレスなどの)にも基づく受信データを処理しないのを除いたビット。 リピータは、MACアドレスがない、MAC実現を全く持たないで、また処理のためにパケットを上位レベル・プロトコル実体まで通過しません。
(When a network management entity is observing the repeater, it may appear as though the repeater is passing packets to a higher-level protocol entity. However, this is only a means of implementing management, and this passing of management information is not part of the repeater functionality.)
(ネットワークマネージメント実体がリピータを観測しているとき、まるでリピータが上位レベル・プロトコル実体にパケットを通過しているかのように見えるかもしれません。 しかしながら、これは管理を実行する手段にすぎません、そして、経営情報のこの通過はリピータの機能性の一部ではありません。)
3.5. Textual Conventions
3.5. 原文のコンベンション
The datatype MacAddress is used as a textual convention in this document. This textual convention has NO effect on either the syntax nor the semantics of any managed object. Objects defined using this convention are always encoded by means of the rules that define their primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate this textual convention which is adopted merely for the convenience of readers.
データ型式MacAddressは原文のコンベンションとして本書では使用されます。 この原文のコンベンションは構文で効き目がありません。または、どんな管理オブジェクトの意味論。 このコンベンションを使用することで定義された物は彼らのプリミティブ型を定義する規則によっていつもコード化されます。 したがって、SMIかSNMPへのどんな変化も、単に読者の都合のために採用されるこの原文のコンベンションを収容するのに必要ではありません。
4. Definitions
4. 定義
SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
SNMPリピータMIB定義:、:= 始まってください。
IMPORTS
Counter, TimeTicks, Gauge
FROM RFC1155-SMI
mib-2, DisplayString FROM RFC1213-MIB
TRAP-TYPE FROM RFC-1215
OBJECT-TYPE FROM RFC-1212;
IMPORTS Counter、TimeTicks、Gauge FROM RFC1155-SMI mib-2、DisplayString FROM RFC1213-MIB TRAP-TYPE FROM RFC-1215 OBJECT-TYPE FROM RFC-1212。
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
snmpDot3RptrMgt物の識別子:、:= mib-2 22
-- All representations of MAC addresses in this MIB Module use, -- as a textual convention (i.e., this convention does not affect -- their encoding), the data type:
-- このMIB Module使用における、MACアドレスのすべての表現--原文のコンベンションとしての、(すなわち、このコンベンションはどんな感情もしません--それらのコード化)、データ型:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in
-- the "canonical" order
-- defined by IEEE 802.1a, i.e., as if it were transmitted least
-- significant bit first.
MacAddress:、:= OCTET STRING、(SIZE(6))--中のすなわち、まるでそれが最も最少に伝えられるかのようにIEEE 802.1aによって定義された6八重奏アドレス(「正準な」オーダー)--重要なビット1番目。
McMaster & McCloghrie [Page 11] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[11ページ]RFC1368 802.3リピータMIB1992年10月
-- References -- -- The following references are used throughout this MIB: -- -- [IEEE 802.3 Std] -- refers to IEEE 802.3/ISO 8802-3 Information processing -- systems - Local area networks - Part 3: Carrier sense -- multiple access with collision detection (CSMA/CD) -- access method and physical layer specifications -- (2nd edition, September 21, 1990). -- -- [IEEE 802.3 Rptr Mgt] -- refers to IEEE P802.3K, 'Layer Management for 10 Mb/s -- Baseband Repeaters, Section 19,' Draft Supplement to -- ANSI/IEEE 802.3, (Draft 8, April 9, 1992)
-- 参照----以下の参照はこのMIB中で使用されます: -- -- [IEEE802.3Std]--IEEE802.3/ISO8802-3情報処理--システム--ローカル・エリア・ネットワーク--パート3について言及します: キャリア検知--衝突検出(CSMA/CD)による複数のアクセス--アクセス法と物理的な層の仕様--(1990年9月21日の2番目の版。) -- -- [IEEE802.3Rptr Mgt]--IEEE P802.3Kが、'Managementを10Mb/s層にしてください--ベースバンドRepeaters、セクション19'と言及する、Draft Supplement、--ANSI/IEEE802.3(草稿8、1992年4月9日)
-- MIB Groups -- -- The rptrBasicPackage group is mandatory. -- The rptrMonitorPackage and rptrAddrTrackPackage -- groups are optional.
-- MIB Groups----rptrBasicPackageグループは義務的です。 -- rptrMonitorPackageとrptrAddrTrackPackage--グループは任意です。
rptrBasicPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
rptrBasicPackage物の識別子:、:= snmpDot3RptrMgt1
rptrMonitorPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
rptrMonitorPackage物の識別子:、:= snmpDot3RptrMgt2
rptrAddrTrackPackage
OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
rptrAddrTrackPackage物の識別子:、:= snmpDot3RptrMgt3
-- object identifiers for organizing the information -- in the groups by repeater, port-group, and port
-- リピータ、ポートグループ、およびポートのそばでグループで情報を組織化するための物の識別子
rptrRptrInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
rptrGroupInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
rptrPortInfo
OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
rptrRptrInfo物の識別子:、:= rptrBasicPackage1rptrGroupInfo物の識別子:、:= rptrBasicPackage2rptrPortInfo物の識別子:、:= rptrBasicPackage3
rptrMonitorRptrInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
rptrMonitorGroupInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
rptrMonitorRptrInfo物の識別子:、:= rptrMonitorPackage1rptrMonitorGroupInfo物の識別子:、:= rptrMonitorPackage2
McMaster & McCloghrie [Page 12] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[12ページ]RFC1368 802.3リピータMIB1992年10月
rptrMonitorPortInfo
OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
rptrMonitorPortInfo物の識別子:、:= rptrMonitorPackage3
rptrAddrTrackRptrInfo -- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
rptrAddrTrackGroupInfo -- this subtree is currently unused
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
rptrAddrTrackPortInfo
OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
rptrAddrTrackRptrInfo--この下位木は現在未使用のOBJECT IDENTIFIERです:、:= rptrAddrTrackPackage1rptrAddrTrackGroupInfo--この下位木は現在未使用のOBJECT IDENTIFIERです:、:= rptrAddrTrackPackage2rptrAddrTrackPortInfo物の識別子:、:= rptrAddrTrackPackage3
-- -- The BASIC GROUP -- -- Implementation of the Basic Group is mandatory for all -- managed repeaters.
-- -- BASIC GROUP----Basic Groupの実現はすべてに義務的です--リピータを管理します。
-- -- Basic Repeater Information -- -- Configuration, status, and control objects for the overall -- repeater --
-- -- 基本のRepeater情報(--構成、状態、および総合的のためのコントロール物--リピータ)
rptrGroupCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupCapacity is the number of groups
that can be contained within the repeater. Within
each managed repeater, the groups are uniquely
numbered in the range from 1 to rptrGroupCapacity.
rptrGroupCapacity OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述、「rptrGroupCapacityはリピータの中に含むことができるグループの数です」。 それぞれの管理されたリピータの中では、グループは1〜rptrGroupCapacityまでの範囲で唯一付番されます。
Some groups may not be present in the repeater, in
which case the actual number of groups present
will be less than rptrGroupCapacity. The number
of groups present will never be greater than
rptrGroupCapacity.
グループの中には、より少ないところにグループの実数が提示するどちらのケースがリピータ、rptrGroupCapacityよりなるか存在していないものもあるかもしれません。 グループの現在の数はrptrGroupCapacityより決して大きくなくなるでしょう。
Note: In practice, this will generally be the
number of field-replaceable units (i.e., modules,
cards, or boards) that can fit in the physical
repeater enclosure, and the group numbers will
correspond to numbers marked on the physical
enclosure."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterGroupCapacity."
以下に注意してください。 「実際には、一般に、これは物理的なリピータ包囲をうまくはめ込むことができる分野取替え可能なユニット(すなわち、モジュール、カード、または板)の数になるでしょう、そして、グループ番号は物理的な包囲に印を付けられた数に対応するでしょう。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.3、.2、aRepeaterGroupCapacity、」
McMaster & McCloghrie [Page 13] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[13ページ]RFC1368 802.3リピータMIB1992年10月
::= { rptrRptrInfo 1 }
::= rptrRptrInfo1
rptrOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- undefined or unknown status
ok(2), -- no known failures
rptrFailure(3), -- repeater-related failure
groupFailure(4), -- group-related failure
portFailure(5), -- port-related failure
generalFailure(6) -- failure, unspecified type
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrOperStatus object indicates the
operational state of the repeater. The
rptrHealthText object may be consulted for more
specific information about the state of the
repeater's health.
rptrOperStatus OBJECT-TYPE SYNTAX INTEGER、他の(1)--未定義の、または、未知の状態OK(2)--知られている失敗rptrFailure(3)がありません--リピータ関連の失敗groupFailure(4)--グループ関連の失敗portFailure(5)--ポート関連の失敗generalFailure(6)--失敗、ACCESS書き込み禁止STATUS記述が「リピータの操作上の状態を示rptrOperStatusが反対するすること」が義務的な不特定のタイプ。 rptrHealthText物はリピータの健康の状態の、より特定の情報のために相談されるかもしれません。
In the case of multiple kinds of failures (e.g.,
repeater failure and port failure), the value of
this attribute shall reflect the highest priority
failure in the following order:
複数の種類の失敗(例えば、リピータ失敗とポートの故障)の場合では、この属性の値は以下のオーダーに最優先失敗を反映するものとします:
rptrFailure(3)
groupFailure(4)
portFailure(5)
generalFailure(6)."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aRepeaterHealthState."
::= { rptrRptrInfo 2 }
"rptrFailure(3) groupFailure(4) portFailure(5) generalFailure(6)"。 参照、「参照IEEE802.3Rptr Mgt、19.2、.3、.2、aRepeaterHealthState、」 ::= rptrRptrInfo2
rptrHealthText OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The health text object is a text string that
provides information relevant to the operational
state of the repeater. Agents may use this string
to provide detailed information on current
failures, including how they were detected, and/or
instructions for problem resolution. The contents
are agent-specific."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
rptrHealthText OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .255))のACCESSの書き込み禁止のSTATUSの義務的な記述、「健康テキストオブジェクトはリピータの操作上の状態に関連している情報を提供するテキスト文字列です」。 エージェントは現在の失敗の詳細な情報を提供するのにこのストリングを使用するかもしれません、それらがどう検出されたか、そして、そして/または、問題解決のための指示を含んでいて。 「内容はエージェント特有です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.3 .2インチ
McMaster & McCloghrie [Page 14] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[14ページ]RFC1368 802.3リピータMIB1992年10月
aRepeaterHealthText."
::= { rptrRptrInfo 3 }
"aRepeaterHealthText"。 ::= rptrRptrInfo3
rptrReset OBJECT-TYPE
SYNTAX INTEGER {
noReset(1),
reset(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to reset(2) causes a
transition to the START state of Fig 9-2 in
section 9 [IEEE 802.3 Std].
rptrReset OBJECT-TYPE SYNTAX INTEGER、noReset(1)、ACCESSが「リセット(2)にこの物を設定すると図9-2のSTART事情への変遷はセクション9[IEEE802.3Std]で引き起こされる」STATUSの義務的な記述を読書して書くリセット(2)。
Setting this object to noReset(1) has no effect.
The agent will always return the value noReset(1)
when this object is read.
この物をnoReset(1)に設定するのは効き目がありません。 この物が読まれるとき、エージェントはいつも値のnoReset(1)を返すでしょう。
This action does not reset the management counters
defined in this document nor does it affect the
portAdminStatus parameters. Included in this
action is the execution of a disruptive Self-Test
with the following characteristics: a) The nature
of the tests is not specified. b) The test resets
the repeater but without affecting management
information about the repeater. c) The test does
not inject packets onto any segment. d) Packets
received during the test may or may not be
transferred. e) The test does not interfere with
management functions.
この動作は本書では定義された管理カウンタをリセットしません、そして、それはportAdminStatusパラメタに影響しません。 この動作に含まれているのは、以下の特性がある破壊的なSelf-テストの実行です: a) テストの本質が指定されない、b) リピータにもかかわらず、リピータに関する経営情報に影響しないで、テストは. c)をリセットします。 テストがどんなセグメントにもパケットを注入しない、d) テストの間に受け取られたパケットを移すかもしれない、e) テストは管理機能を妨げません。
As a result of this action a rptrResetEvent trap
should be sent."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acResetRepeater."
::= { rptrRptrInfo 4 }
「この動作の結果、rptrResetEvent罠を送るべきです。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.3、.3、acResetRepeater、」 ::= rptrRptrInfo4
rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to selfTest(2) causes the
rptrNonDisruptTest OBJECT-TYPE SYNTAX INTEGER、noSelfTest(1)、ACCESSがSTATUS義務的な記述を読書して書くselfTest(2)、「selfTest(2)原因にこの物を設定する、」
McMaster & McCloghrie [Page 15] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[15ページ]RFC1368 802.3リピータMIB1992年10月
repeater to perform a agent-specific, non-
disruptive self-test that has the following
characteristics: a) The nature of the tests is
not specified. b) The test does not change the
state of the repeater or management information
about the repeater. c) The test does not inject
packets onto any segment. d) The test does not
prevent the relay of any packets. e) The test
does not interfere with management functions.
以下の特性を持っているエージェント特有の、そして、非破壊的な自己診断を実行するリピータ: a) テストの本質が指定されない、b) テストがリピータに関するリピータか経営情報の状態を変えない、c) テストがどんなセグメントにもパケットを注入しない、d) テストがどんなパケットのリレーも防がない、e) テストは管理機能を妨げません。
After performing this test the agent will update
the repeater health information and send a
rptrHealth trap.
このテストを実行した後に、エージェントは、リピータ健康情報をアップデートして、rptrHealth罠を送るでしょう。
Setting this object to noSelfTest(1) has no
effect. The agent will always return the value
noSelfTest(1) when this object is read."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3,
acExecuteNonDisruptiveSelfTest."
::= { rptrRptrInfo 5 }
この物をnoSelfTest(1)に設定するのは効き目がありません。 「この物が読まれるとき、エージェントはいつも値のnoSelfTest(1)を返すでしょう。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.3、.3、acExecuteNonDisruptiveSelfTest、」 ::= rptrRptrInfo5
rptrTotalPartitionedPorts OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object returns the total number of ports in
the repeater whose current state meets all three
of the following criteria: rptrPortOperStatus
does not have the value notPresent(3),
rptrPortAdminStatus is enabled(1), and
rptrPortAutoPartitionState is autoPartitioned(2)."
::= { rptrRptrInfo 6 }
rptrTotalPartitionedPorts OBJECT-TYPE SYNTAX Gauge ACCESSの書き込み禁止のSTATUSの義務的な記述、「この物は現状が以下のすべての3つの評価基準に会うリピータのポートの総数を返します」。 「rptrPortOperStatusには値のnotPresent(3)がなくて、rptrPortAdminStatusが有効にされる、(1)、rptrPortAutoPartitionStateがautoPartitioned(2)である、」 ::= rptrRptrInfo6
-- -- The Basic Port Group Table --
-- -- 基本的なポートグループテーブル--
rptrGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the groups of ports."
::= { rptrGroupInfo 1 }
rptrGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrGroupEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「ポートのグループの描写的、そして、状態情報のテーブル。」 ::= rptrGroupInfo1
McMaster & McCloghrie [Page 16] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[16ページ]RFC1368 802.3リピータMIB1992年10月
rptrGroupEntry OBJECT-TYPE
SYNTAX RptrGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single group of ports."
INDEX { rptrGroupIndex }
::= { rptrGroupTable 1 }
rptrGroupEntry OBJECT-TYPE SYNTAX RptrGroupEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「ポートのただ一つのグループの情報を含むテーブルのエントリー。」 rptrGroupIndexに索引をつけてください:、:= rptrGroupTable1
RptrGroupEntry ::=
SEQUENCE {
rptrGroupIndex
INTEGER,
rptrGroupDescr
DisplayString,
rptrGroupObjectID
OBJECT IDENTIFIER,
rptrGroupOperStatus
INTEGER,
rptrGroupLastOperStatusChange
TimeTicks,
rptrGroupPortCapacity
INTEGER
}
RptrGroupEntry:、:= 系列rptrGroupIndex整数、rptrGroupDescr DisplayString、rptrGroupObjectID物の識別子、rptrGroupOperStatus整数、rptrGroupLastOperStatusChange TimeTicks、rptrGroupPortCapacity整数
rptrGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information. This value is never greater than
rptrGroupCapacity."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupID."
::= { rptrGroupEntry 1 }
rptrGroupIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むリピータの中でグループを特定これが反対するします」。 「この値はrptrGroupCapacityより決して大きくはありません。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.5、.2、aGroupID、」 ::= rptrGroupEntry1
rptrGroupDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the group. This value
should include the full name and version
identification of the group's hardware type and
rptrGroupDescr OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .255))のACCESSの書き込み禁止のSTATUSの義務的な記述、「グループの原文の記述。」 そしてこの値がグループのハードウェアタイプのフルネームとバージョン識別を含むべきである。
McMaster & McCloghrie [Page 17] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[17ページ]RFC1368 802.3リピータMIB1992年10月
indicate how the group is differentiated from
other groups in the repeater. Plug-in Module, Rev
A' or 'Barney Rubble 10BASE-T 4-port SIMM socket
Version 2.1' are examples of valid group
descriptions.
グループがリピータで他のグループとどう区別されるかを示してください。 プラグイン'Moduleか、Rev A'4ポートの'バニーRubble 10BASE-T SIMMソケットバージョン2.1'が有効なグループ記述に関する例です。
It is mandatory that this only contain printable
ASCII characters."
::= { rptrGroupEntry 2 }
「これが印刷可能なASCII文字を含むだけであるのは、義務的です。」 ::= rptrGroupEntry2
rptrGroupObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
group. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides a
straight-forward and unambiguous means for
determining what kind of group is being managed.
グループのrptrGroupObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESSのSTATUSの義務的な記述正式の書き込み禁止「業者識別、」 SMI企業下位木の中にこの値を割り当てる、(1.3、.6、.1、.4、.1、)、どういうグループが経営されているかを決定するための簡単で明白な手段を提供します。
For example, this object could take the value
1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones,
Inc.' was assigned the subtree 1.3.6.1.4.1.4242,
and had assigned the identifier
1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone
6-Port FOIRL Plug-in Module.'"
::= { rptrGroupEntry 3 }
「例えば、この物が値1.3の.6を取るかもしれない、.1、.4、.1、.4242、.1、.2、下位木1.3が業者'フリントストーンInc.'であるなら.14に割り当てられた、.6、.1、.4、.1、.4242、識別子1.3.6を割り当てた、.1、.4、.1、.4242、.1、.2、'6ポートのウィルマFlintstone中のFOIRL Plug Module'への.14、」、:、:= rptrGroupEntry3
rptrGroupOperStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
operational(2),
malfunctioning(3),
notPresent(4),
underTest(5),
resetInProgress(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that indicates the operational status
of the group.
rptrGroupOperStatus OBJECT-TYPE SYNTAX INTEGER、他の(1)、操作上の(2)、誤動作している(3)、notPresent(4)、underTest(5)、resetInProgress(6)、ACCESSの書き込み禁止のSTATUSの義務的な記述、「グループの操作上の状態を示す物。」
A status of notPresent(4) indicates that the group
is temporarily or permanently physically and/or
logically not a part of the repeater. It is an
implementation-specific matter as to whether the
notPresent(4)の状態は、グループがリピータの一時的か永久に物理的論理的にそうしていないa部分であることを示します。 それがそう、実現詳細は重要です。
McMaster & McCloghrie [Page 18] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[18ページ]RFC1368 802.3リピータMIB1992年10月
agent effectively removes notPresent entries from
the table.
事実上、エージェントはテーブルからnotPresentエントリーを取り除きます。
A status of operational(2) indicates that the
group is functioning, and a status of
malfunctioning(3) indicates that the group is
malfunctioning in some way."
::= { rptrGroupEntry 4 }
「操作上の(2)の状態は、グループが機能しているのを示します、そして、誤動作(3)の状態はグループが何らかの方法で誤動作しているのを示します。」 ::= rptrGroupEntry4
rptrGroupLastOperStatusChange OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An object that contains the value of sysUpTime at
the time that the value of the rptrGroupOperStatus
object for this group last changed.
rptrGroupLastOperStatusChange OBJECT-TYPE SYNTAX TimeTicks ACCESSの書き込み禁止のSTATUSの義務的な記述、「このグループのためのrptrGroupOperStatus物の値が持続する時にsysUpTimeの値を含む物は変化しました」。
A value of zero indicates that the group's oper
status has not changed since the agent last
restarted."
::= { rptrGroupEntry 5 }
「ゼロの値は、エージェントが最後に再開して以来グループのoper状態が今まで変わっていないのを示します。」 ::= rptrGroupEntry5
rptrGroupPortCapacity OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The rptrGroupPortCapacity is the number of ports
that can be contained within the group. Valid
range is 1-1024. Within each group, the ports are
uniquely numbered in the range from 1 to
rptrGroupPortCapacity.
rptrGroupPortCapacity OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述、「rptrGroupPortCapacityはグループの中に含むことができるポートの数です」。 有効枠は1-1024です。 各グループの中では、ポートは1〜rptrGroupPortCapacityまでの範囲で唯一付番されます。
Note: In practice, this will generally be the
number of ports on a module, card, or board, and
the port numbers will correspond to numbers marked
on the physical embodiment."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2,
aGroupPortCapacity."
::= { rptrGroupEntry 6 }
以下に注意してください。 「実際には、一般に、これはモジュール、カード、または板でポートの数になるでしょう、そして、ポートナンバーは物理的な具体化のときに印を付けられた数に対応するでしょう。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.5、.2、aGroupPortCapacity、」 ::= rptrGroupEntry6
McMaster & McCloghrie [Page 19] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[19ページ]RFC1368 802.3リピータMIB1992年10月
-- -- The Basic Port Table --
-- -- 基本的なポートテーブル--
rptrPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of descriptive and status information about
the ports."
::= { rptrPortInfo 1 }
rptrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrPortEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「ポートの描写的、そして、状態情報のテーブル。」 ::= rptrPortInfo1
rptrPortEntry OBJECT-TYPE
SYNTAX RptrPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing information
about a single port."
INDEX { rptrPortGroupIndex, rptrPortIndex }
::= { rptrPortTable 1 }
rptrPortEntry OBJECT-TYPE SYNTAX RptrPortEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「単一のポートの情報を含むテーブルのエントリー。」 rptrPortGroupIndex、rptrPortIndexに索引をつけてください:、:= rptrPortTable1
RptrPortEntry ::=
SEQUENCE {
rptrPortGroupIndex
INTEGER,
rptrPortIndex
INTEGER,
rptrPortAdminStatus
INTEGER,
rptrPortAutoPartitionState
INTEGER,
rptrPortOperStatus
INTEGER
}
RptrPortEntry:、:= 系列rptrPortGroupIndex整数、rptrPortIndex整数、rptrPortAdminStatus整数、rptrPortAutoPartitionState整数、rptrPortOperStatus整数
rptrPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrPortEntry 1 }
rptrPortGroupIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むポートを含むグループを特定これが反対するします」。 ::= rptrPortEntry1
rptrPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
rptrPortIndexオブジェクト・タイプ構文整数(1..1024)
McMaster & McCloghrie [Page 20] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[20ページ]RFC1368 802.3リピータMIB1992年10月
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information. This
value can never be greater than
rptrGroupPortCapacity for the associated group."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrPortEntry 2 }
ACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むグループの中でポートを特定これが反対するします」。 「この値はrptrGroupPortCapacityより関連グループにすばらしいはずがありません。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aPortID、」 ::= rptrPortEntry2
rptrPortAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to disabled(2) disables the
port. A disabled port neither transmits nor
receives. Once disabled, a port must be
explicitly enabled to restore operation. A port
which is disabled when power is lost or when a
reset is exerted shall remain disabled when normal
operation resumes.
rptrPortAdminStatus OBJECT-TYPE SYNTAX INTEGERは(1)、障害がある(2)を可能にしました。ACCESSは「身体障害者(2)にこの物を設定すると、ポートは無能にされること」をSTATUSの義務的な記述に読書して書きます。 障害があるポートは、伝わらないで、また受信されません。 いったん無能にされると、操作を復元するのを明らかにポートを可能にしなければなりません。 通常の操作が再開するとき、パワーが無くなるか、またはリセットが出されるとき障害があるポートは障害があったままで残っているものとします。
The admin status takes precedence over auto-
partition and functionally operates between the
auto-partition mechanism and the AUI/PMA.
アドミン状態は、自動パーティションに優先して、自動パーティションメカニズムとAUI/PMAの間で機能上作動します。
Setting this object to enabled(1) enables the port
and exerts a BEGIN on the port's auto-partition
state machine.
(In effect, when a port is disabled, the value of
rptrPortAutoPartitionState for that port is frozen
until the port is next enabled. When the port
becomes enabled, the rptrPortAutoPartitionState
becomes notAutoPartitioned(1), regardless of its
pre-disabling state.)"
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortAdminState and 19.2.6.3, acPortAdminControl."
::= { rptrPortEntry 3 }
この物を可能にされるのに設定して、(1)はポートの自動パーティション州のマシンにポートを可能にして、BEGINを出します。 (事実上、ポートは障害があるとき、ポートが可能にされた状態で次になるまで、そのポートへのrptrPortAutoPartitionStateの値が凍っています。 ポートが可能にされるようになると、状態をあらかじめ無効にすることにかかわらずrptrPortAutoPartitionStateはnotAutoPartitioned(1)になります。)そして、「参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aPortAdminState、19.2 .6 .3 acPortAdminControl、」、」 ::= rptrPortEntry3
rptrPortAutoPartitionState OBJECT-TYPE
SYNTAX INTEGER {
rptrPortAutoPartitionStateオブジェクト・タイプ構文整数
McMaster & McCloghrie [Page 21] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[21ページ]RFC1368 802.3リピータMIB1992年10月
notAutoPartitioned(1),
autoPartitioned(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The autoPartitionState flag indicates whether the
port is currently partitioned by the repeater's
auto-partition protection.
notAutoPartitioned(1)、autoPartitioned(2) 「ポートが現在リピータの自動パーティション保護で仕切られるか否かに関係なく、autoPartitionState旗は示す」ACCESSの書き込み禁止のSTATUSの義務的な記述。
The conditions that cause port partitioning are
specified in partition state machine in Section 9
[IEEE 802.3 Std]. They are not differentiated
here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitionState."
::= { rptrPortEntry 4 }
ポート仕切りを引き起こす状態はセクション9[IEEE802.3Std]でパーティション州のマシンで指定されます。 「それらはここで微分されません。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aAutoPartitionState、」 ::= rptrPortEntry4
rptrPortOperStatus OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
notOperational(2),
notPresent(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object indicates the port's operational
status. The notPresent(3) status indicates the
port is physically removed (note this may or may
not be possible depending on the type of port.)
rptrPortOperStatus OBJECT-TYPE SYNTAX INTEGER、操作上の(1)、notOperational(2)、ACCESS読書だけSTATUS記述が「ポートの操作上の状態を示これが反対するすること」が義務的なnotPresent(3)。 notPresent(3)状態は、ポートが物理的に取り外されるのを示します。(ポートのタイプに頼っていて、これが可能であるかもしれないことに注意してください。)
The operational(1) status indicates that the port
is enabled (see rptrPortAdminStatus) and working,
even though it might be auto-partitioned (see
rptrPortAutoPartitionState).
操作上の(1)状態は、ポートが可能にされ(rptrPortAdminStatusを見る)て働くのを示します、それは自動仕切られるかもしれませんが(rptrPortAutoPartitionStateを見てください)。
If this object has the value operational(1) and
rptrPortAdminStatus is set to disabled(2), it is
expected that this object's value will change to
notOperational(2) soon after."
::= { rptrPortEntry 5 }
「この物がそうしたなら、値の操作上の(1)とrptrPortAdminStatusは身体障害者(2)に用意ができて、この物の値がすぐ後にnotOperational(2)に変化すると予想されます。」 ::= rptrPortEntry5
McMaster & McCloghrie [Page 22] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[22ページ]RFC1368 802.3リピータMIB1992年10月
-- -- The MONITOR GROUP -- -- Implementation of this group is optional, but within the -- group all elements are mandatory. If a managed repeater -- implements any part of this group, the entire group shall -- be implemented.
-- -- 分類してください。MONITOR GROUP----このグループの実現が任意である、中、--、すべての要素が義務的です。 管理されたリピータ(このグループ、全体のグループのどんな部分もそうする道具)であるなら、実行されてください。
-- -- Repeater Monitor Information -- -- Performance monitoring statistics for the repeater --
-- -- リピータMonitor情報----リピータのためのパフォーマンスのモニターしている統計、--
rptrMonitorTransmitCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented every time the
repeater state machine enters the TRANSMIT
COLLISION state from any state other than ONE PORT
LEFT (Ref: Fig 9-2, IEEE 802.3 Std).
rptrMonitorTransmitCollisions OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「リピータ州のマシンがONE PORT LEFT(審判: 図9-2、IEEE802.3Std)以外のどんな状態からもTRANSMIT COLLISION状態に入るときはいつも、このカウンタは増加されています」。
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
aTransmitCollisions."
::= { rptrMonitorRptrInfo 1 }
「このカウンタのロールオーバーのための大体の最小の時間は16時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.3、.2、aTransmitCollisions、」 ::= rptrMonitorRptrInfo1
-- -- The Group Monitor Table --
-- -- グループはテーブルをモニターします--
rptrMonitorGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of performance and error statistics for the
groups."
::= { rptrMonitorGroupInfo 1 }
rptrMonitorGroupTable OBJECT-TYPEのSYNTAX SEQUENCE OF RptrMonitorGroupEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「グループのための性能と誤り統計のテーブル。」 ::= rptrMonitorGroupInfo1
rptrMonitorGroupEntry OBJECT-TYPE
SYNTAX RptrMonitorGroupEntry
rptrMonitorGroupEntryオブジェクト・タイプ構文RptrMonitorGroupEntry
McMaster & McCloghrie [Page 23] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[23ページ]RFC1368 802.3リピータMIB1992年10月
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing total
performance and error statistics for a single
group. Regular retrieval of the information in
this table provides a means of tracking the
performance and health of the networked devices
attached to this group's ports.
「シングルのためのテーブル、総性能を含んで、および誤り統計におけるエントリーは分類する」ACCESSのアクセスしやすくないSTATUS義務的な記述。 このテーブルでの情報の定期的な検索はこのグループのポートに取り付けられたネットワークでつながれた装置の性能と健康を追跡する手段を提供します。
The counters in this table are redundant in the
sense that they are the summations of information
already available through other objects. However,
these sums provide a considerable optimization of
network management traffic over the otherwise
necessary retrieval of the individual counters
included in each sum."
INDEX { rptrMonitorGroupIndex }
::= { rptrMonitorGroupTable 1 }
このテーブルのカウンタはそれらが他の物を通して既に利用可能な情報の足し算であるという意味で余分です。 「しかしながら、各合計に個々のカウンタのそうでなければ、必要な検索の上のネットワークマネージメント交通のかなりの最適化を含んでいて、これらの合計は提供されます。」 rptrMonitorGroupIndexに索引をつけてください:、:= rptrMonitorGroupTable1
RptrMonitorGroupEntry ::=
SEQUENCE {
rptrMonitorGroupIndex
INTEGER,
rptrMonitorGroupTotalFrames
Counter,
rptrMonitorGroupTotalOctets
Counter,
rptrMonitorGroupTotalErrors
Counter
}
RptrMonitorGroupEntry:、:= 系列rptrMonitorGroupIndex整数、rptrMonitorGroupTotalFramesカウンタ、rptrMonitorGroupTotalErrorsが打ち返すrptrMonitorGroupTotalOctetsカウンタ
rptrMonitorGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group within the
repeater for which this entry contains
information."
::= { rptrMonitorGroupEntry 1 }
rptrMonitorGroupIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むリピータの中でグループを特定これが反対するします」。 ::= rptrMonitorGroupEntry1
rptrMonitorGroupTotalFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of frames of valid frame length
rptrMonitorGroupTotalFrames OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述は「有効なフレームの長さのフレームの総数」です。
McMaster & McCloghrie [Page 24] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[24ページ]RFC1368 802.3リピータMIB1992年10月
that have been received on the ports in this
group. This counter is the summation of the
values of the rptrMonitorPortReadableFrames
counters for all of the ports in the group.
このグループのポートの上にそれを受け取りました。 このカウンタはグループにおける、ポートのすべてのためのrptrMonitorPortReadableFramesカウンタの値の足し算です。
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
::= { rptrMonitorGroupEntry 2 }
この統計値はパケット誤り率を得るのに必要なパラメタの1つを提供します。 「このカウンタのロールオーバーのための大体の最小の時間は80時間です。」 ::= rptrMonitorGroupEntry2
rptrMonitorGroupTotalOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of octets contained in the valid
frames that have been received on the ports in
this group. This counter is the summation of the
values of the rptrMonitorPortReadableOctets
counters for all of the ports in the group.
「八重奏の総数はこのグループのポートの上に受け取られた有効なフレームに含んだ」rptrMonitorGroupTotalOctets OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述。 このカウンタはグループにおける、ポートのすべてのためのrptrMonitorPortReadableOctetsカウンタの値の足し算です。
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
::= { rptrMonitorGroupEntry 3 }
この統計値は移された総データのインディケータを提供します。 「このカウンタのロールオーバーのための大体の最小の時間は58分です。」 ::= rptrMonitorGroupEntry3
rptrMonitorGroupTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
all of the ports in this group. This counter is
the summation of the values of the
rptrMonitorPortTotalErrors counters for all of the
ports in the group."
::= { rptrMonitorGroupEntry 4 }
rptrMonitorGroupTotalErrors OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「これにポートのすべてに発生した誤りの総数は分類します」。 「このカウンタはグループにおける、ポートのすべてのためのrptrMonitorPortTotalErrorsカウンタの値の足し算です。」 ::= rptrMonitorGroupEntry4
-- -- The Port Monitor Table --
-- -- ポートモニターテーブル--
rptrMonitorPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
rptrMonitorPortTable OBJECT-TYPEのSYNTAX SEQUENCE OF RptrMonitorPortEntry ACCESSのアクセスしやすくないSTATUS義務的です。
McMaster & McCloghrie [Page 25] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[25ページ]RFC1368 802.3リピータMIB1992年10月
DESCRIPTION
"Table of performance and error statistics for the
ports."
::= { rptrMonitorPortInfo 1 }
記述、「ポートへの性能と誤り統計のテーブル。」 ::= rptrMonitorPortInfo1
rptrMonitorPortEntry OBJECT-TYPE
SYNTAX RptrMonitorPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing performance and
error statistics for a single port."
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
::= { rptrMonitorPortTable 1 }
「シングルのためのテーブルのエントリー、性能を含んで、および誤り統計は移植する」rptrMonitorPortEntry OBJECT-TYPE SYNTAX RptrMonitorPortEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 rptrMonitorPortGroupIndex、rptrMonitorPortIndexに索引をつけてください:、:= rptrMonitorPortTable1
RptrMonitorPortEntry ::=
SEQUENCE {
rptrMonitorPortGroupIndex
INTEGER,
rptrMonitorPortIndex
INTEGER,
rptrMonitorPortReadableFrames
Counter,
rptrMonitorPortReadableOctets
Counter,
rptrMonitorPortFCSErrors
Counter,
rptrMonitorPortAlignmentErrors
Counter,
rptrMonitorPortFrameTooLongs
Counter,
rptrMonitorPortShortEvents
Counter,
rptrMonitorPortRunts
Counter,
rptrMonitorPortCollisions
Counter,
rptrMonitorPortLateEvents
Counter,
rptrMonitorPortVeryLongEvents
Counter,
rptrMonitorPortDataRateMismatches
Counter,
rptrMonitorPortAutoPartitions
Counter,
rptrMonitorPortTotalErrors
Counter
}
RptrMonitorPortEntry:、:= 系列{ rptrMonitorPortGroupIndex整数、rptrMonitorPortIndex整数、rptrMonitorPortReadableFramesは反対して、rptrMonitorPortReadableOctetsは反対して、rptrMonitorPortFCSErrorsは反対して、rptrMonitorPortAlignmentErrorsは反対して、rptrMonitorPortFrameTooLongsは反対して、rptrMonitorPortShortEventsは反対します; rptrMonitorPortRuntsは反対して、rptrMonitorPortCollisionsは反対して、rptrMonitorPortLateEventsは反対して、rptrMonitorPortVeryLongEventsは反対して、rptrMonitorPortDataRateMismatchesは反対して、rptrMonitorPortAutoPartitionsは反対して、rptrMonitorPortTotalErrorsは反対します; }
McMaster & McCloghrie [Page 26] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[26ページ]RFC1368 802.3リピータMIB1992年10月
rptrMonitorPortGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrMonitorPortEntry 1 }
rptrMonitorPortGroupIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むポートを含むグループを特定これが反対するします」。 ::= rptrMonitorPortEntry1
rptrMonitorPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrMonitorPortEntry 2 }
rptrMonitorPortIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むグループの中でポートを特定これが反対するします」。 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aPortID、」 ::= rptrMonitorPortEntry2
rptrMonitorPortReadableFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the number of frames of valid
frame length that have been received on this port.
This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1) and for which the FCSError and
CollisionEvent signals are not asserted.
rptrMonitorPortReadableFrames OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述は「これが、反対するこのポートの上に受け取られた有効なフレームの長さのフレームの数です」。 このカウンタがOctetCountがこと以上であるこのポートの上に受け取られた各フレームあたり1つ増加される、minFrameSizeと、よりmaxFrameSize、(審判: IEEE802.3Std、4.4 .2 .1) そして、FCSErrorとCollisionEvent信号がどれでないかために、断言されていません。
This statistic provides one of the parameters
necessary for obtaining the packet error rate.
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableFrames."
::= { rptrMonitorPortEntry 3 }
この統計値はパケット誤り率を得るのに必要なパラメタの1つを提供します。 「このカウンタのロールオーバーのための大体の最小の時間は80時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aReadableFrames、」 ::= rptrMonitorPortEntry3
rptrMonitorPortReadableOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
rptrMonitorPortReadableOctets OBJECT-TYPE SYNTAX Counter ACCESS書き込み禁止STATUS義務的です。
McMaster & McCloghrie [Page 27] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[27ページ]RFC1368 802.3リピータMIB1992年10月
DESCRIPTION
"This object is the number of octets contained in
valid frames that have been received on this port.
This counter is incremented by OctetCount for each
frame received on this port which has been
determined to be a readable frame.
記述は「これが、反対するこのポートの上に受け取られた有効なフレームに含まれた八重奏の数です」。 このカウンタはOctetCountによってこの読み込み可能なフレームであると決心しているポートの上に受け取られた各フレームに増加されます。
This statistic provides an indicator of the total
data transferred. The approximate minimum time
for rollover of this counter is 58 minutes."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aReadableOctets."
::= { rptrMonitorPortEntry 4 }
この統計値は移された総データのインディケータを提供します。 「このカウンタのロールオーバーのための大体の最小の時間は58分です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aReadableOctets、」 ::= rptrMonitorPortEntry4
rptrMonitorPortFCSErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError signal
asserted and the FramingError and CollisionEvent
signals deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
Std).
rptrMonitorPortFCSErrors OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタがFCSError信号が断言されて、FramingErrorとCollisionEvent信号が反断言されているこのポートとOctetCountがだれのものであるかに関して、より受け取られた各フレームあたり1つ増加される、minFrameSizeと、よりmaxFrameSize、(審判: 4.4、.2、.1、IEEE802.3Std)、」
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFrameCheckSequenceErrors."
::= { rptrMonitorPortEntry 5 }
「このカウンタのロールオーバーのための大体の最小の時間は80時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aFrameCheckSequenceErrors、」 ::= rptrMonitorPortEntry5
rptrMonitorPortAlignmentErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port with the FCSError and
FramingError signals asserted and CollisionEvent
signal deasserted and whose OctetCount is greater
than or equal to minFrameSize and less than or
equal to maxFrameSize (Ref: IEEE 802.3 Std,
4.4.2.1). If rptrMonitorPortAlignmentErrors is
incremented then the rptrMonitorPortFCSErrors
rptrMonitorPortAlignmentErrors OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタがFCSErrorとFramingError信号が断言されて、CollisionEvent信号が反断言されているこのポートとOctetCountがだれのものであるかに関して、より受け取られた各フレームあたり1つ増加される、minFrameSizeと、よりmaxFrameSize、(審判: IEEE802.3Std、4.4、.2、.1)、」 rptrMonitorPortAlignmentErrorsがその時増加される、rptrMonitorPortFCSErrors
McMaster & McCloghrie [Page 28] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[28ページ]RFC1368 802.3リピータMIB1992年10月
Counter shall not be incremented for the same
frame.
同じフレームにカウンタを増加しないものとします。
The approximate minimum time for rollover of this
counter is 80 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAlignmentErrors."
::= { rptrMonitorPortEntry 6 }
「このカウンタのロールオーバーのための大体の最小の時間は80時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aAlignmentErrors、」 ::= rptrMonitorPortEntry6
rptrMonitorPortFrameTooLongs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port whose OctetCount is greater
than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
If rptrMonitorPortFrameTooLongs is incremented
then neither the rptrMonitorPortAlignmentErrors
nor the rptrMonitorPortFCSErrors counter shall be
incremented for the frame.
rptrMonitorPortFrameTooLongs OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタがOctetCountがmaxFrameSizeよりすばらしいこのポートの上に受け取られた各フレームあたり1つ増加される、(審判: 4.4、.2、.1、IEEE802.3Std)、」 rptrMonitorPortFrameTooLongsが増加されているなら、rptrMonitorPortAlignmentErrorsもrptrMonitorPortFCSErrorsカウンタもフレームに増加しないものとします。
The approximate minimum time for rollover of this
counter is 61 days."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aFramesTooLong."
::= { rptrMonitorPortEntry 7 }
「このカウンタのロールオーバーのための大体の最小の時間は61日間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aFramesTooLong、」 ::= rptrMonitorPortEntry7
rptrMonitorPortShortEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port with ActivityDuration
less than ShortEventMaxTime. ShortEventMaxTime is
greater than 74 bit times and less than 82 bit
times. ShortEventMaxTime has tolerances included
to provide for circuit losses between a
conformance test point at the AUI and the
measurement point within the state machine.
rptrMonitorPortShortEvents OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「ActivityDurationがShortEventMaxTimeより少ない状態でこのカウンタはこのポートの上の各CarrierEventあたり1つ増加されます」。 ShortEventMaxTimeは74ビットの倍と82ビットの倍です。 ShortEventMaxTimeは、回線損失に備えるために寛容をAUIの順応テストポイントと州のマシンの中の測定ポイントの間含ませています。
Note: shortEvents may indicate externally
generated noise hits which will cause the repeater
to transmit Runts to its other ports, or propagate
a collision (which may be late) back to the
以下に注意してください。 shortEventsは、他のポートにRuntsを送るか、または衝突(遅れるかもしれない)後部を伝播するためにリピータを引き起こす外部的に発生した雑音ヒットを示すかもしれません。
McMaster & McCloghrie [Page 29] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[29ページ]RFC1368 802.3リピータMIB1992年10月
transmitting DTE and damaged frames to the rest of
the network.
DTEと破損しているフレームをネットワークの残りに伝えます。
Implementors may wish to consider selecting the
ShortEventMaxTime towards the lower end of the
allowed tolerance range to accommodate bit losses
suffered through physical channel devices not
budgeted for within this standard.
作成者は、許容寛容範囲の下側の端に向かったShortEventMaxTimeが損失がこの規格の中に予算を立てられなかった物理的なチャンネル装置を通して受けたビットを収容するのを選択すると考えたがっているかもしれません。
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aShortEvents."
::= { rptrMonitorPortEntry 8 }
「このカウンタのロールオーバーのための大体の最小の時間は16時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aShortEvents、」 ::= rptrMonitorPortEntry8
rptrMonitorPortRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port that meets one of the
following two conditions. Only one test need be
made. a) The ActivityDuration is greater than
ShortEventMaxTime and less than ValidPacketMinTime
and the CollisionEvent signal is deasserted. b)
The OctetCount is less than 64, the
ActivityDuration is greater than ShortEventMaxTime
and the CollisionEvent signal is deasserted.
ValidPacketMinTime is greater than or equal to 552
bit times and less than 565 bit times.
rptrMonitorPortRunts OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタは以下の2つの条件の1つに会うこのポートの上の各CarrierEventあたり1つ増加されます」。 テストがされなければならない唯一のものa) ActivityDurationがShortEventMaxTimeと以下よりValidPacketMinTimeよりすばらしく、CollisionEvent信号がdeasserted. bである、) OctetCountは64歳未満です、そして、ActivityDurationはShortEventMaxTimeよりすばらしいです、そして、CollisionEvent信号は反断言されます。 ValidPacketMinTimeは552ビットの倍と565ビットの倍です。
An event whose length is greater than 74 bit times
but less than 82 bit times shall increment either
the shortEvents counter or the runts counter but
not both. A CarrierEvent greater than or equal to
552 bit times but less than 565 bit times may or
may not be counted as a runt.
ちびは、長さが回であるにすぎない出来事がshortEventsカウンタを増加するというわけではないものとしますし、反対しますが、またともに反対するというわけではありません。 CarrierEventより多くの552は回に噛み付きましたが、565ビットの倍はちびにみなされるかもしれません。
ValidPacketMinTime has tolerances included to
provide for circuit losses between a conformance
test point at the AUI and the measurement point
within the state machine.
ValidPacketMinTimeは、回線損失に備えるために寛容をAUIの順応テストポイントと州のマシンの中の測定ポイントの間含ませています。
Runts usually indicate collision fragments, a
normal network event. In certain situations
associated with large diameter networks a
通常、ちびは衝突断片、正常なネットワークイベントを示します。 大きさに関連しているある状況で、直径はaをネットワークでつなぎます。
McMaster & McCloghrie [Page 30] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[30ページ]RFC1368 802.3リピータMIB1992年10月
percentage of runts may exceed ValidPacketMinTime.
ちびの割合はValidPacketMinTimeを超えるかもしれません。
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts."
::= { rptrMonitorPortEntry 9 }
「このカウンタのロールオーバーのための大体の最小の時間は16時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aRunts、」 ::= rptrMonitorPortEntry9
rptrMonitorPortCollisions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for any
CarrierEvent signal on any port for which the
CollisionEvent signal on this port is asserted.
rptrMonitorPortCollisions OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタはこのポートの上のCollisionEvent信号が断言されるどんなポートの上のどんなCarrierEvent信号のためにも1つ増加されます」。
The approximate minimum time for rollover of this
counter is 16 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aCollisions."
::= { rptrMonitorPortEntry 10 }
「このカウンタのロールオーバーのための大体の最小の時間は16時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aCollisions、」 ::= rptrMonitorPortEntry10
rptrMonitorPortLateEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port in which the CollIn(X)
variable transitions to the value SQE (Ref:
9.6.6.2, IEEE 802.3 Std) while the
ActivityDuration is greater than the
LateEventThreshold. Such a CarrierEvent is
counted twice, as both a collision and as a
lateEvent.
rptrMonitorPortLateEvents OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタがCollIn(X)変数が値のSQEに移行するこのポートの上の各CarrierEventあたり1つ増加される、(審判: 9.6、.6、.2、IEEE802.3Std)、ActivityDurationがLateEventThresholdよりすばらしい、」 そのようなCarrierEventは衝突とlateEventのように二度数えられます。
The LateEventThreshold is greater than 480 bit
times and less than 565 bit times.
LateEventThreshold has tolerances included to
permit an implementation to build a single
threshold to serve as both the LateEventThreshold
and ValidPacketMinTime threshold.
LateEventThresholdは480ビットの倍と565ビットの倍です。 LateEventThresholdは、実現が両方としてLateEventThresholdとValidPacketMinTime敷居に役立つようにただ一つの敷居を築き上げることを許可するために寛容を含ませています。
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
「このカウンタのロールオーバーのための大体の最小の時間は81時間です。」 参照
McMaster & McCloghrie [Page 31] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[31ページ]RFC1368 802.3リピータMIB1992年10月
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLateEvents."
::= { rptrMonitorPortEntry 11 }
「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aLateEvents、」 ::= rptrMonitorPortEntry11
rptrMonitorPortVeryLongEvents OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each
CarrierEvent on this port whose ActivityDuration
is greater than the MAU Jabber Lockup Protection
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
Other counters may be incremented as appropriate."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aVeryLongEvents."
::= { rptrMonitorPortEntry 12 }
rptrMonitorPortVeryLongEvents OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタがActivityDurationがMAU Jabber Lockup ProtectionタイマTW3よりすばらしいこのポートの上の各CarrierEventあたり1つ増加される、(審判: 9.6.1と9.6、.5、IEEE802.3Std)、」 「他のカウンタは適宜増加されるかもしれません。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aVeryLongEvents、」 ::= rptrMonitorPortEntry12
rptrMonitorPortDataRateMismatches OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each frame
received on this port that meets all of the
following conditions: a) The CollisionEvent
signal is not asserted. b) The ActivityDuration
is greater than ValidPacketMinTime. c) The
frequency (data rate) is detectably mismatched
from the local transmit frequency. The exact
degree of mismatch is vendor specific and is to be
defined by the vendor for conformance testing.
rptrMonitorPortDataRateMismatches OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタは以下の条件のすべてに会うこのポートの上に受け取られた各フレームあたり1つ増加されます」。 a) CollisionEvent信号は. b)であると断言されません。 ActivityDurationがValidPacketMinTime. cよりすばらしい、) 頻度(データ信号速度)は地方の送信周波数からdetectablyにミスマッチされます。 正確な度のミスマッチは、業者特有であり、順応テストのために業者によって定義されることです。
When this event occurs, other counters whose
increment conditions were satisfied may or may not
also be incremented, at the implementor's
discretion. Whether or not the repeater was able
to maintain data integrity is beyond the scope of
this standard."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aDataRateMismatches."
::= { rptrMonitorPortEntry 13 }
また、この出来事が起こるとき、増分の状態が満たされた他のカウンタは増加されるかもしれません、作成者の裁量で。 「リピータがデータ保全を維持できたかどうかがこの規格の範囲を超えています。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aDataRateMismatches、」 ::= rptrMonitorPortEntry13
rptrMonitorPortAutoPartitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
rptrMonitorPortAutoPartitions OBJECT-TYPE SYNTAX Counter ACCESS書き込み禁止
McMaster & McCloghrie [Page 32] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[32ページ]RFC1368 802.3リピータMIB1992年10月
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
the repeater has automatically partitioned this
port. The conditions that cause port partitioning
are specified in the partition state machine in
Section 9 [IEEE 802.3 Std]. They are not
differentiated here."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aAutoPartitions."
::= { rptrMonitorPortEntry 14 }
STATUSの義務的な記述、「このカウンタはリピータが自動的にこのポートを仕切った各回あたり1つ増加されます」。 ポート仕切りを引き起こす状態はセクション9[IEEE802.3Std]でパーティション州のマシンで指定されます。 「それらはここで微分されません。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aAutoPartitions、」 ::= rptrMonitorPortEntry14
rptrMonitorPortTotalErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of errors which have occurred on
this port. This counter is the summation of the
values of other error counters (for the same
port), namely:
rptrMonitorPortTotalErrors OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このポートに発生した誤りの総数。」 このカウンタ、もう一方の値の足し算はすなわち、誤りカウンタ(同じポートに)です:
rptrMonitorPortFCSErrors,
rptrMonitorPortAlignmentErrors,
rptrMonitorPortFrameTooLongs,
rptrMonitorPortShortEvents,
rptrMonitorPortLateEvents,
rptrMonitorPortVeryLongEvents, and
rptrMonitorPortDataRateMismatches.
rptrMonitorPortFCSErrors、rptrMonitorPortAlignmentErrors、rptrMonitorPortFrameTooLongs、rptrMonitorPortShortEvents、rptrMonitorPortLateEvents、rptrMonitorPortVeryLongEvents、およびrptrMonitorPortDataRateMismatches。
This counter is redundant in the sense that it is
the summation of information already available
through other objects. However, it is included
specifically because the regular retrieval of this
object as a means of tracking the health of a port
provides a considerable optimization of network
management traffic over the otherwise necessary
retrieval of the summed counters."
::= { rptrMonitorPortEntry 15 }
このカウンタはそれが他の物を通して既に利用可能な情報の足し算であるという意味で余分です。 「しかしながら、特にポートの健康を追跡する手段としてのこの物の定期的な検索がまとめられたカウンタのそうでなければ、必要な検索の上にネットワークマネージメント交通のかなりの最適化を提供するので、それは含まれています。」 ::= rptrMonitorPortEntry15
-- -- The ADDRESS TRACKING GROUP -- -- Implementation of this group is optional; it is appropriate -- for all systems which have the necessary metering. If a -- managed repeater implements any part of this group, the entire
-- -- ADDRESS TRACKING GROUP----このグループの実現は任意です。 必要な計量を持っているすべてのシステムに、それは適切です。 a--リピータを管理するのが何かこのグループ、全体の部分を実行するなら
McMaster & McCloghrie [Page 33] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[33ページ]RFC1368 802.3リピータMIB1992年10月
-- group shall be implemented.
-- グループは実行されるものとします。
-- -- The Port Address Tracking Table --
-- -- ポートアドレス追跡テーブル--
rptrAddrTrackTable OBJECT-TYPE
SYNTAX SEQUENCE OF RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of address mapping information about the
ports."
::= { rptrAddrTrackPortInfo 1 }
rptrAddrTrackTable OBJECT-TYPEのSYNTAX SEQUENCE OF RptrAddrTrackEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「ポートに関するアドレスマッピング情報のテーブル。」 ::= rptrAddrTrackPortInfo1
rptrAddrTrackEntry OBJECT-TYPE
SYNTAX RptrAddrTrackEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table, containing address mapping
information about a single port."
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
::= { rptrAddrTrackTable 1 }
rptrAddrTrackEntry OBJECT-TYPE SYNTAX RptrAddrTrackEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、「単一のポートに関するアドレスマッピング情報を含むテーブルのエントリー。」 rptrAddrTrackGroupIndex、rptrAddrTrackPortIndexに索引をつけてください:、:= rptrAddrTrackTable1
RptrAddrTrackEntry ::=
SEQUENCE {
rptrAddrTrackGroupIndex
INTEGER,
rptrAddrTrackPortIndex
INTEGER,
rptrAddrTrackLastSourceAddress
MacAddress,
rptrAddrTrackSourceAddrChanges
Counter
}
RptrAddrTrackEntry:、:= 系列rptrAddrTrackGroupIndex整数、rptrAddrTrackPortIndex整数、rptrAddrTrackSourceAddrChangesが打ち返すrptrAddrTrackLastSourceAddress MacAddress
rptrAddrTrackGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the group containing the
port for which this entry contains information."
::= { rptrAddrTrackEntry 1 }
rptrAddrTrackGroupIndex OBJECT-TYPE SYNTAX INTEGER(1 .1024)のACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むポートを含むグループを特定これが反対するします」。 ::= rptrAddrTrackEntry1
rptrAddrTrackPortIndex OBJECT-TYPE
SYNTAX INTEGER (1..1024)
rptrAddrTrackPortIndexオブジェクト・タイプ構文整数(1..1024)
McMaster & McCloghrie [Page 34] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[34ページ]RFC1368 802.3リピータMIB1992年10月
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the port within the group
for which this entry contains information."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aPortID."
::= { rptrAddrTrackEntry 2 }
ACCESSの書き込み禁止のSTATUSの義務的な記述は「このエントリーが情報を含むグループの中でポートを特定これが反対するします」。 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aPortID、」 ::= rptrAddrTrackEntry2
rptrAddrTrackLastSourceAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object is the SourceAddress of the last
readable frame (i.e., counted by
rptrMonitorPortReadableFrames) received by this
port."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aLastSourceAddress."
::= { rptrAddrTrackEntry 3 }
rptrAddrTrackLastSourceAddress OBJECT-TYPE SYNTAX MacAddress ACCESSの書き込み禁止のSTATUSの義務的な記述は「これが、反対するこのポートによって受け取られた最後の読み込み可能なフレーム(すなわち、rptrMonitorPortReadableFramesが数えられる)のSourceAddressです」。 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aLastSourceAddress、」 ::= rptrAddrTrackEntry3
rptrAddrTrackSourceAddrChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This counter is incremented by one for each time
that the rptrAddrTrackLastSourceAddress attribute
for this port has changed.
rptrAddrTrackSourceAddrChanges OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述、「このカウンタはこのポートへのrptrAddrTrackLastSourceAddress属性が変化した各回あたり1つ増加されます」。
This may indicate whether a link is connected to a
single DTE or another multi-user segment.
The approximate minimum time for rollover of this
counter is 81 hours."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2,
aSourceAddressChanges."
::= { rptrAddrTrackEntry 4 }
これは、リンクが独身のDTEか別のマルチユーザセグメントに接続されるかどうかを示すかもしれません。 「このカウンタのロールオーバーのための大体の最小の時間は81時間です。」 参照、「参照IEEE802.3Rptr Mgt、19.2、.6、.2、aSourceAddressChanges、」 ::= rptrAddrTrackEntry4
-- Traps for use by Repeaters
-- Repeatersによる使用のために罠
-- Traps are defined using the conventions in RFC 1215 [8].
-- 罠は、RFC1215[8]でコンベンションを使用することで定義されます。
rptrHealth TRAP-TYPE
rptrHealth罠タイプ
McMaster & McCloghrie [Page 35] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[35ページ]RFC1368 802.3リピータMIB1992年10月
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrHealth trap conveys information related
to the operational status of the repeater. This
trap is sent only when the oper status of the
repeater changes.
エンタープライズsnmpDot3RptrMgt VARIABLES rptrOperStatus、記述、「rptrHealth罠はリピータの操作上の状態に関連する情報を伝えます」。 リピータのoper状態が変化するときだけ、この罠を送ります。
The rptrHealth trap must contain the
rptrOperStatus object. The agent may optionally
include the rptrHealthText object in the varBind
list. See the rptrOperStatus and rptrHealthText
objects for descriptions of the information that
is sent.
rptrHealth罠はrptrOperStatus物を含まなければなりません。 エージェントはvarBindリストで任意にrptrHealthText物を入れるかもしれません。 送られる情報の記述に関してrptrOperStatusとrptrHealthText物を見てください。
The agent must throttle the generation of
consecutive rptrHealth traps so that there is at
least a five-second gap between them."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
hubHealth notification."
::= 1
「エージェントはそれらの間には、少なくとも5秒のギャップがあるように、連続したrptrHealth罠の世代を阻止しなければなりません。」 REFERENCE、「参照IEEE802.3Rptr Mgt、19.2、.3、.4、hubHealth通知、」 ::= 1
rptrGroupChange TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrGroupIndex }
DESCRIPTION
"This trap is sent when a change occurs in the
group structure of a repeater. This occurs only
when a group is logically or physically removed
from or added to a repeater. The varBind list
contains the identifier of the group that was
removed or added.
rptrGroupChange TRAP-TYPEエンタープライズsnmpDot3RptrMgt VARIABLES rptrGroupIndex、「変化がリピータの集団構造に起こるときこの罠を送る」記述。 グループが論理的か物理的に移されるか、またはリピータに加えられるときだけ、これは起こります。 varBindリストは取り除いたか、または加えたグループに関する識別子を含んでいます。
The agent must throttle the generation of
consecutive rptrGroupChange traps for the same
group so that there is at least a five-second gap
between them."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4,
groupMapChange notification."
::= 2
「それらの間には、少なくとも5秒のギャップがあって、エージェントは同じグループのために連続したrptrGroupChange罠の世代を阻止しなければなりません。」 REFERENCE、「参照IEEE802.3Rptr Mgt、19.2、.3、.4、groupMapChange通知、」 ::= 2
rptrResetEvent TRAP-TYPE
ENTERPRISE snmpDot3RptrMgt
VARIABLES { rptrOperStatus }
DESCRIPTION
"The rptrResetEvent trap conveys information
rptrResetEvent TRAP-TYPEエンタープライズsnmpDot3RptrMgt VARIABLES rptrOperStatus、記述、「rptrResetEvent罠は情報を伝達します」。
McMaster & McCloghrie [Page 36] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[36ページ]RFC1368 802.3リピータMIB1992年10月
related to the operational status of the repeater.
This trap is sent on completion of a repeater
reset action. A repeater reset action is defined
as an a transition to the START state of Fig 9-2
in section 9 [IEEE 802.3 Std], when triggered by a
management command (e.g., an SNMP Set on the
rptrReset object).
リピータの操作上の状態に関連しました。 リピータリセット動作の完成にこの罠を送ります。 セクション9[IEEE802.3Std]でリピータリセット動作は図9-2のSTART事情へのa変遷と定義されます、管理命令(例えば、rptrReset物の上のSNMP Set)で引き起こされると。
The agent must throttle the generation of
consecutive rptrResetEvent traps so that there is
at least a five-second gap between them.
エージェントは、それらの間には、少なくとも5秒のギャップがあるように、連続したrptrResetEvent罠の世代を阻止しなければなりません。
The rptrResetEvent trap is not sent when the agent
restarts and sends an SNMP coldStart or warmStart
trap. However, it is recommended that a repeater
agent send the rptrOperStatus object as an
optional object with its coldStart and warmStart
trap PDUs.
エージェントがSNMP coldStartかwarmStart罠を再開して、送るとき、rptrResetEvent罠は送られません。 しかしながら、リピータエージェントがcoldStartとwarmStart罠PDUsがある任意の物としてrptrOperStatus物を送るのは、お勧めです。
The rptrOperStatus object must be included in the
varbind list sent with this trap. The agent may
optionally include the rptrHealthText object as
well."
REFERENCE
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset
notification."
::= 3
この罠と共に送られたvarbindリストにrptrOperStatus物を含まなければなりません。 「エージェントは任意にまた、rptrHealthText物を入れるかもしれません。」 REFERENCE、「参照IEEE802.3Rptr Mgt、19.2、.3、.4、hubReset通知、」 ::= 3
END
終わり
5. Acknowledgments
5. 承認
This document is the work of the IETF Hub MIB Working Group. It is based on drafts of the IEEE 802.3 Repeater Management Task Force. Members of the working group included:
このドキュメントはIETF Hub MIB作業部会の仕事です。 それはIEEE802.3Repeater Management Task Forceの草稿に基づいています。 ワーキンググループのメンバーは:だった
Karl Auerbach karl@eng.sun.com
Jim Barnes barnes@xylogics.com
Steve Bostock steveb@novell.com
David Bridgham dab@asylum.sf.ca.us
Jack Brown jbrown@huahuca-emh8.army.mil
Howard Brown brown@ctron.com
Lida Canin lida@apple.com
Jeffrey Case case@cs.utk.edu
Carson Cheung carson@bnr.com.ca
James Codespote jpcodes@tycho.ncsc.mil
John Cook cook@chipcom.com
Dave Cullerot cullerot@ctron.com
カールアウアーバック karl@eng.sun.com ジムバーンズ barnes@xylogics.com スティーブBostock steveb@novell.com デヴィッドBridgham dab@asylum.sf.ca.us ジャックブラウン jbrown@huahuca-emh8.army.mil ハワードブラウン brown@ctron.com リダケーニン lida@apple.com ジェフリーケース case@cs.utk.edu カーソンチェン carson@bnr.com.ca ジェームスCodespote jpcodes@tycho.ncsc.mil ション・クック cook@chipcom.com デーヴCullerot cullerot@ctron.com
McMaster & McCloghrie [Page 37] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[37ページ]RFC1368 802.3リピータMIB1992年10月
James Davin jrd@ptt.lcs.mit.edu
Gary Ellis garye@hpspd.spd.hp.com
David Engel david@cds.com
Mike Erlinger mike@mti.com
Jeff Erwin
Bill Fardy fardy@ctron.com
Jeff Fried jmf@relay.proteon.com
Bob Friesenhahn pdrusa!bob@uunet.uu.net
Shawn Gallagher gallagher@quiver.enet.dec.com
Mike Grieves mgrieves@chipcom.com
Walter Guilarte 70026.1715@compuserve.com
Phillip Hasse phasse@honchuca-emh8.army.mil
Mark Hoerth mark_hoerth@hp0400.desk.hp.com
Greg Hollingsworth gregh@mailer.jhuapl.edu
Ron Jacoby rj@sgi.com
Mike Janson mjanson@mot.com
Ken Jones konkord!ksj@uunet.uu.net
Satish Joshi sjoshi@synoptics.com
Frank Kastenholz kasten@europa.clearpoint.com
Manu Kaycee kaycee@trlian.enet.dec.com
Mark Kepke mak@cnd.hp.com
Mark Kerestes att!alux2!hawk@uunet.uu.net
Kenneth Key key@cs.utk.edu
Yoav Kluger ykluger@fibhaifa.com
Cheryl Krupczak cheryl@cc.gatech.edu
Ron Lau rlau@synoptics.com
Chao-Yu Liang cliang@synoptics.com
Dave Lindemulder da@mtung.att.com
Richie McBride rm@bix.co.uk
Keith McCloghrie kzm@hls.com
Evan McGinnis bem@3com.com
Donna McMaster mcmaster@synoptics.com
David Minnich dwm@fibercom.com
Lynn Monsanto monsanto@sun.com
Miriam Nihart miriam@decwet.zso.dec.com
Niels Ole Brunsgaard nob@dowtyns.dk
Edison Paw esp@3com.com
David Perkins dperkins@synoptics.com
Jason Perreault perreaul@interlan.interlan.com
John Pickens jrp@3com.com
Jim Reinstedler jimr@sceng.ub.com
Anil Rijsinghani anil@levers.enet.dec.com
Sam Roberts sroberts@farallon.com
Dan Romascanu dan@lannet.com
Marshall Rose mrose@dbc.mtview.ca.us
Rick Royston rick@lsumus.sncc.lsu.edu
Michael Sabo sabo@dockmaster.ncsc.mil
Jonathan Saperia saperia@tcpjon.enet.dec.com
ジェームス・デーヴィン・ jrd@ptt.lcs.mit.edu ゲーリー・エリス・ garye@hpspd.spd.hp.com デヴィッド・エンゲル・ david@cds.com マイク・Erlinger mike@mti.com ジェフ・アーウィン・ビル・Fardy fardy@ctron.com ジェフ・フリード・ jmf@relay.proteon.com ボブ・Friesenhahn pdrusa!bob@uunet.uu.net ショーン・ギャラガー・ gallagher@quiver.enet.dec.com マイクは mgrieves@chipcom.com ウォルターGuilarte 70026.1715@compuserve.com フィリップハッセ phasse@honchuca-emh8.army.mil マークHoerth mark_hoerth@hp0400.desk.hp.com グレッグホリングスワース gregh@mailer.jhuapl.edu ロンジャコービー rj@sgi を悲しませます; comマイクジャンソン mjanson@mot.com ケンジョーンズ konkord!ksj@uunet.uu.net サティシュジョーシー sjoshi@synoptics.com フランクKastenholz kasten@europa.clearpoint.com マヌーKaycee kaycee@trlian.enet.dec.com マークKepke mak@cnd.hp.com マークKerestes att!alux2!hawk@uunet.uu ネットのケネス・ rm@bix.co.uk キース・McCloghrie kzm@hls.com エヴァン・Key key@cs.utk.edu Yoavクリューガー ykluger@fibhaifa.com シェリルKrupczak cheryl@cc.gatech.edu ロンラウ rlau@synoptics.com チャオ-ユーLiang cliang@synoptics.com デーヴLindemulder da@mtung.att.com リッチーマックブライドマクギニス m@3com.com ドナマクマスター mcmaster@synoptics.com デヴィッドミンニヒ dwm@fibercom.com リンモンサント monsanto@sun.com ミリアムNihart miriam@decwet.zso.dec.com ニールズOle Brunsgaard nob@dowtyns.dk エディソン足 esp@3com.com デヴィッドパーキンス dperkins@synoptics.com ジェイソンペロー perreaul@interlan.interlan.com ジョンピケンズ jrp@3com comジムReinstedler jimr@sceng.ub.com Anil Rijsinghani anil@levers.enet.dec.com サムロバーツ sroberts@farallon.com ダンRomascanu dan@lannet.com マーシャルローズ mrose@dbc.mtview.ca.us リックRoyston rick@lsumus.sncc.lsu.edu マイケルSabo sabo@dockmaster.ncsc.mil ジョナサンSaperia saperia@tcpjon.enet.dec.com
McMaster & McCloghrie [Page 38] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[38ページ]RFC1368 802.3リピータMIB1992年10月
Mark Schaefer schaefer@davidsys.com
Anil Singhal nsinghal@hawk.ulowell.edu
Timon Sloane peernet!timon@uunet.uu.net
Bob Stewart rlstewart@eng.xyplex.com
Emil Sturniolo emil@dss.com
Bruce Taber taber@interlan.com
Iris Tal 437-3580@mcimail.com
Mark Therieau markt@python.eng.microcom.com
Geoff Thompson thompson@synoptics.com
Dean Throop throop@dg-rtp.dg.com
Steven Waldbusser waldbusser@andrew.cmu.edu
Timothy Walden tmwalden@saturn.sys.acc.com
Philip Wang watadn!phil@uunet.uu.net
Drew Wansley dwansley@secola.columbia.ncr.com
David Ward dward@chipcom.com
Steve Wong wong@took.enet.dec.com
Paul Woodruff paul-woodruff@3com.com
Brian Wyld brianw@spider.co.uk
June-Kang Yang natadm!yang@uunet.uu.net
Henry Yip natadm!henry@uunet.uu.net
John Ziegler ziegler@artel.com
Joseph Zur fibronics!zur@uunet.uu.net
シェーファー schaefer@davidsys.com コマツナギSinghal nsinghal@hawk.ulowell.edu タイモンスローン peernet!timon@uunet.uu.net ボブ・スチュワート rlstewart@eng.xyplex.com エミールSturniolo emil@dss.com ブルーステーバー taber@interlan.com 虹彩タル 437-3580@mcimail.com マークTherieau markt@python.eng.microcom.com ジェフトンプソン thompson@synoptics.com ディーンThroopが throop@dg-rtp.dg.com スティーブンWaldbusser waldbusser@andrew.cmu であるとマークしてください; eduティモシーウォルデン tmwalden@saturn.sys.acc.com フィリップワング watadn!phil@uunet.uu.net ドリューWansley dwansley@secola.columbia.ncr.com デヴィッド区 dward@chipcom.com スティーブWong wong@took.enet.dec.com ポールWoodruff paul-woodruff@3com.com ブライアンワイルドbrianw@spider.co.uk6月-カンYang natadm!yang@uunet.uu.net ヘンリーイップ natadm!henry@uunet.uu.net ジョンジーグラー ziegler@artel.com ジョゼフZur fibronics!zur@uunet.uu.net
6. References
6. 参照
[1] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
[1]ローズM.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155、国際パフォーマンスSystemsヒューズLAN Systems(1990年5月)
[2] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[2]McCloghrie K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1156、ヒューズLAN Systems、国際パフォーマンスSystems、1990年5月。
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[3] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[4] Rose M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213,
Performance Systems International, March 1991.
[4] ローズM.、Editor、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、国際言語運用機構、1991年3月。
[5] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[5] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構国際規格8824(1987年12月)の仕様。
McMaster & McCloghrie [Page 39] RFC 1368 802.3 Repeater MIB October 1992
マクマスターとMcCloghrie[39ページ]RFC1368 802.3リピータMIB1992年10月
[6] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[6] 情報処理システム--オープン・システム・インターコネクション--抽象的なNotation One(ASN.1)、国際標準化機構国際規格8825(1987年12月)のためのBasic Encoding Rulesの仕様。
[7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[7] ローズ、M.とK.McCloghrie、エディターズ、「簡潔なMIB定義」、STD16、RFC1212、国際言語運用機構、ヒューズLANシステム(1991年3月)。
[8] Rose, M., Editor, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, Performance Systems International, March
1991.
[8] ローズ、M.、Editor、「SNMPとの使用のためのDefining TrapsのためのConvention」、RFC1215、国際パフォーマンスSystems、1991年3月。
[9] IEEE 802.3/ISO 8802-3 Information processing systems - Local area
networks - Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer
specifications, 2nd edition, September 21, 1990.
[9] IEEE802.3/ISO8802-3情報処理システム--ローカル・エリア・ネットワーク--パート3: 衝突検出(CSMA/CD)アクセス法と物理的な層の仕様、2番目の版、1990年9月21日がある搬送波感知多重アクセス。
[10] IEEE P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters,
Section 19," Draft Supplement to ANSI/IEEE 802.3, Draft 8, April
9, 1992.
[10] IEEE P802.3K、「10Mb/sのベースバンドリピータのための管理を層にしてください、セクション19」(ANSI/IEEE802.3への草稿補足)は1992年4月9日に8を作成します。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Authors' Addresses
8. 作者のアドレス
Donna McMaster SynOptics Communications, Inc. 4401 Great America Parkway P.O. Box 58185 Santa Clara, CA 95052-8185
公園道路P.O. Box58185サンタクララ、ドナマクマスターSynOptics Communications Inc.4401Great Americaカリフォルニア95052-8185
EMail: mcmaster@synoptics.com
メール: mcmaster@synoptics.com
Keith McCloghrie Hughes LAN Systems, Inc. 1225 Charleston Road Mountain View, CA 94043
マウンテンビュー、キースMcCloghrieヒューズLANシステムInc.1225チャールストンRoadカリフォルニア 94043
Phone: (415) 966-7934 EMail: kzm@hls.com
以下に電話をしてください。 (415) 966-7934 メールしてください: kzm@hls.com
McMaster & McCloghrie [Page 40]
マクマスターとMcCloghrie[40ページ]
一覧
スポンサーリンク
