RFC1573 日本語訳
1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F.Kastenholz. January 1994. (Format: TXT=123057 bytes) (Obsoletes RFC1229) (Obsoleted by RFC2233) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. McCloghrie
Request for Comments: 1573 Hughes LAN Systems
Obsoletes: 1229 F. Kastenholz
Category: Standards Track FTP Software
January 1994
McCloghrieがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1573台のヒューズLANシステムが以下を時代遅れにします。 1229年のF.Kastenholzカテゴリ: 標準化過程FTPソフトウェア1994年1月
Evolution of the Interfaces Group of MIB-II
MIB-IIのインタフェースグループの発展
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ............................................. 2 2. The SNMPv2 Network Management Framework .................. 2 2.1 Object Definitions ...................................... 3 3 Experience with the Interfaces Group ...................... 3 3.1 Areas of Clarification/Revision ......................... 3 3.1.1 Interface Numbering ................................... 4 3.1.2 Interface Sub-Layers .................................. 4 3.1.3 Virtual Circuits ...................................... 5 3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 5 3.1.5 Counter Size .......................................... 5 3.1.6 Interface Speed ....................................... 6 3.1.7 Multicast/Broadcast Counters .......................... 6 3.1.8 Addition of New ifType values ......................... 6 3.1.9 ifSpecific ............................................ 6 3.2 Clarifications/Revisions ................................ 7 3.2.1 Interface Numbering ................................... 7 3.2.2 Interface Sub-Layers .................................. 8 3.2.3 Guidance on Defining Sub-layers ....................... 11 3.2.4 Virtual Circuits ...................................... 12 3.2.5 Bit, Character, and Fixed-Length Interfaces ........... 12 3.2.6 Counter Size .......................................... 14 3.2.7 Interface Speed ....................................... 16 3.2.8 Multicast/Broadcast Counters .......................... 16 3.2.9 Trap Enable ........................................... 17 3.2.10 Addition of New ifType values ........................ 17 3.2.11 InterfaceIndex Textual Convention .................... 17 3.2.12 IfAdminStatus and IfOperStatus ....................... 18 3.2.13 Traps ................................................ 19 3.2.14 ifSpecific ........................................... 20
1. 序論… 2 2. SNMPv2ネットワークマネージメントフレームワーク… 2 2.1 オブジェクト定義… インタフェースの3 3経験は分類されます… 3 明確化/改正の3.1の領域… 3 3.1 .1 付番を連結してください… 4 3.1 .2 副層を連結してください… 4 3.1 .3 仮想の回路… 5 3.1 .4のビット、キャラクター、および固定長は連結します… 5 3.1 .5 サイズを打ち返してください… 5 3.1 .6 速度を連結してください… 6 3.1 .7マルチキャスト/放送は反対します… 6 3.1 New ifType値の.8追加… 6 3.1 .9はifSpecificされます… 6 3.2の明確化/改正… 7 3.2 .1 付番を連結してください… 7 3.2 .2 副層を連結してください… 8 3.2 副層を定義するときの.3指導… 11 3.2 .4 仮想の回路… 12 3.2 .5のビット、キャラクター、および固定長は連結します… 12 3.2 .6 サイズを打ち返してください… 14 3.2 .7 速度を連結してください… 16 3.2 .8マルチキャスト/放送は反対します… 3.2.9罠が可能にする16… 17 3.2 New ifType値の.10追加… 17 3.2 .11 InterfaceIndexの原文のコンベンション… 17 3.2 .12IfAdminStatusとIfOperStatus… 18 3.2 .13 捕らえます… 19 3.2 .14はifSpecificされます… 20
McCloghrie & Kastenholz [Page 1] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[1ページ]RFC1573はグループ発展1994年1月に連結します。
3.3 Media-Specific MIB Applicability ........................ 20 4. Overview ................................................. 21 5. IANAifType Definition .................................... 22 6. Interfaces Group Definitions ............................. 24 7. Acknowledgements ......................................... 53 8. References ............................................... 53 9. Security Considerations .................................. 55 10. Authors' Addresses....................................... 55
3.3 メディア特有のMIBの適用性… 20 4. 概要… 21 5. IANAifType定義… 22 6. インタフェースは定義を分類します… 24 7. 承認… 53 8. 参照… 53 9. セキュリティ問題… 55 10. 作者のアドレス… 55
1. Introduction
1. 序論
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはNetwork Interfacesを管理するのに使用される管理オブジェクトについて説明します。
This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It proposes clarifications to, and extensions of, the architectural issues within the current model used for the 'interfaces' group.
このメモは'インタフェース'グループに関連したインターネットワーク層の下で様々な副層を管理する使用のための多数のメディア特有のMIBモジュールの定義から獲得していた状態でMIB-IIの'インタフェース'グループ、特に経験について議論します。 明確化を提案する、拡大、'インタフェース'に使用される現在のモデルの中の構造的な問題は分類されます。
This memo also includes a MIB module. As well as including new MIB definitions to support the architectural extensions, this MIB module also re-specifies the 'interfaces' group of MIB-II in a manner which is both compliant to the SNMPv2 SMI and semantically-identical to the existing SNMPv1-based definitions.
また、このメモはMIBモジュールを含んでいます。 また、建築拡大をサポートするために新しいMIB定義を含んでいることと同様に、このMIBモジュールは既存のSNMPv1ベースの定義とSNMPv2 SMIに対応であって、かつ意味的に同じ方法でMIB-IIの'インタフェース'グループを再指定します。
2. The SNMPv2 Network Management Framework
2. SNMPv2ネットワークマネージメントフレームワーク
The SNMPv2 Network Management Framework consists of four major components. They are:
SNMPv2 Network Management Frameworkは4個の主要コンポーネントから成ります。 それらは以下の通りです。
o RFC 1442 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
o SMI、説明に、中古のメカニズム、および命名を定義するRFC1442は管理の目的のために反対します。
o STD 17, RFC 1213 defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
o STD17、RFC1213はMIB-II、管理オブジェクトの巻き癖をプロトコルのインターネットスイートと定義します。
o RFC 1445 which defines the administrative and other
architectural aspects of the framework.
o フレームワークの管理の、そして、他の建築局面を定義するRFC1445。
o RFC 1448 which defines the protocol used for network access
to managed objects.
o 管理オブジェクトへのネットワークアクセスに使用されるプロトコルを定義するRFC1448。
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
Frameworkは、新しいオブジェクトが実験と評価の目的のために定義されるのを可能にします。
McCloghrie & Kastenholz [Page 2] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[2ページ]RFC1573はグループ発展1994年1月に連結します。
2.1. Object Definitions
2.1. オブジェクト定義
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) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義された抽象的なSyntax Notation One(ASN.1)の部分集合を使用することで定義されます。 特に、それぞれのオブジェクトオブジェクト・タイプはOBJECT IDENTIFIER、行政上割り当てられた名前によって命名されます。 オブジェクトインスタンスに伴うオブジェクト・タイプは、唯一オブジェクトの特定の具体化を特定するのに勤めます。 人間の便宜のために、私たちはしばしば記述子と呼ばれた原文のストリングを使用して、オブジェクトについて言及するのはタイプされます。
3. Experience with the Interfaces Group
3. インタフェースグループの経験
One of the strengths of internetwork-layer protocols such as IP [6] is that they are designed to run over any network interface. In achieving this, IP considers any and all protocols it runs over as a single "network interface" layer. A similar view is taken by other internetwork-layer protocols. This concept is represented in MIB-II by the 'interfaces' group which defines a generic set of managed objects such that any network interface can be managed in an interface-independent manner through these managed objects. The 'interfaces' group provides the means for additional managed objects specific to particular types of network interface (e.g., a specific medium such as Ethernet) to be defined as extensions to the 'interfaces' group for media-specific management. Since the standardization of MIB-II, many such media-specific MIB modules have been defined.
IP[6]などのインターネットワーク層のプロトコルの強さの1つはそれらがどんなネットワーク・インターフェースもひくように設計されているということです。 これを達成する際に、IPはそれがただ一つの「ネットワーク・インターフェース」層として実行するありとあらゆるプロトコルを考えます。 他のインターネットワーク層のプロトコルは同様の意見を取ります。 この概念はMIB-IIにインタフェースから独立している方法でこれらの管理オブジェクトを通してどんなネットワーク・インターフェースにも対処できるように管理オブジェクトのジェネリックセットを定義する'インタフェース'グループによって表されます。 'インタフェース'への拡大がメディア特有の管理のために分類されるとき、'インタフェース'グループは特定のタイプのネットワーク・インターフェース(例えば、イーサネットなどの特定の媒体)に特定の追加管理オブジェクトが定義される手段を提供します。 MIB-IIの標準化以来、そのような多くのメディア特有のMIBモジュールが定義されています。
Experience in defining these media-specific MIB modules has shown that the model defined by MIB-II is too simplistic and/or static for some types of media-specific management. As a result, some of these media-specific MIB modules have assumed an evolution or loosening of the model. This memo is a proposal to document and standardize the evolution of the model and to fill in the gaps caused by that evolution.
これらのメディア特有のMIBモジュールを定義する経験は、何人かのタイプのメディア特有の管理に、MIB-IIによって定義されたモデルが安易過ぎる、そして/または、静的であることを示しました。 その結果、発展であると思われるか、またはモデルに緩んで、これらのメディア特有のMIBモジュールのいくつかはそうしました。 このメモはモデルの発展を記録して、標準化して、その発展によって引き起こされた不足に記入するという提案です。
A previous effort to extend the interfaces group resulted in the publication of RFC 1229 [7]. As part of defining the evolution of the interfaces group, this memo applies that evolution to, and thereby incorporates, the RFC 1229 extensions.
インタフェースグループを広げる前の取り組みはRFC1229[7]の公表をもたらしました。 インタフェースの発展を定義する一部として、グループ、このメモがその発展を当てはまる、その結果、盛込む、1229年のRFC拡張子。
3.1. Areas of Clarification/Revision
3.1. 明確化/改正の領域
There are several areas for which experience indicates that clarification, revision, or extension of the model would be helpful. The next sections discuss these.
経験がモデルの明確化、改正、または拡大が役立っているのを示すいくつかの領域があります。 次のセクションはこれらについて論じます。
McCloghrie & Kastenholz [Page 3] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[3ページ]RFC1573はグループ発展1994年1月に連結します。
3.1.1. Interface Numbering
3.1.1. インタフェース付番
MIB-II defines an object, ifNumber, whose value represents:
MIB-IIはオブジェクト、値が以下を表すifNumberを定義します。
"The number of network interfaces (regardless of their
current state) present on this system."
「ネットワークの数はこのシステムにプレゼントを接続します(彼らの現状にかかわらず)。」
Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value as follows:
各インタフェースはifIndexオブジェクトのユニークな値によって特定されます、そして、ifIndexの記述は以下の値を抑制します:
"Its value ranges between 1 and the value of ifNumber. The
value for each interface must remain constant at least from
one re-initialization of the entity's network management
system to the next re-initialization."
「値はifNumberの1と値の間で及びます。」 「各インタフェースへの値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」
This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. However, an increasing number of devices allow for the dynamic addition/removal of network interfaces. One example of this is a dynamic ability to configure the use of SLIP/PPP over a character-oriented port. For such dynamic additions/removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic.
能率的経営に、特定のインタフェースへのifIndexの値に関するこの不変性要件が必要です。 しかしながら、増加する数のデバイスがネットワーク・インターフェースのダイナミックな追加/取り外しを考慮します。 この1つの例がキャラクタ指向のポートの上でSLIP/PPPの使用を構成するダイナミックな能力です。 そのようなダイナミックな追加/取り外しにおいて、不変性要件の組み合わせとifIndexの値がifNumber以下であるという制限は問題が多いです。
3.1.2. Interface Sub-Layers
3.1.2. インタフェース副層
Experience in defining media-specific management information has shown the need to distinguish between the multiple sub-layers beneath the internetwork-layer. In addition, there is a need to manage these sub-layers in devices (e.g., MAC-layer bridges) which are unaware of which, if any, internetwork protocols run over these sub-layers. As such, a model of having a single conceptual row in the interfaces table (MIB-II's ifTable) represent a whole interface underneath the internetwork-layer, and having a single associated media-specific MIB module (referenced via the ifType object) is too simplistic. A further problem arises with the value of the ifType object which has enumerated values for each type of interface.
メディア特有の経営情報を定義する経験はインターネットワーク層の下の複数の副層を見分ける必要性を示しました。 さらに、もしあれば、インターネットワークプロトコルがどれについてこれらの副層をひくかを気づかない状態でそうするデバイス(例えば、MAC-層のブリッジ)でこれらの副層を管理する必要があります。 そういうものとして、インタフェースのただ一つの概念的な行に(MIB-IIのifTable)をテーブルの上に置かせるモデルはインターネットワーク層の下に全体のインタフェースを表します、そして、ただ一つの関連メディア特有のMIBモジュール(ifTypeオブジェクトを通して、参照をつけられる)を持っているのは安易過ぎます。 さらなる問題はそれぞれのタイプのインタフェースに値を列挙したifTypeオブジェクトの値で起こります。
Consider, for example, an interface with PPP running over an HDLC link which uses a RS232-like connector. Each of these sub-layers has its own media-specific MIB module. If all of this is represented by a single conceptual row in the ifTable, then an enumerated value for ifType is needed for that specific combination which maps to the specific combination of media-specific MIBs. Furthermore, there is still a lack of a method to describe the relationship of all the sub-layers of the MIB stack.
例えばRS232のようなコネクタを使用するHDLCリンクをひくPPPとのインタフェースを考えてください。 それぞれのこれらの副層には、それ自身のメディア特有のMIBモジュールがあります。 このすべてがifTableのただ一つの概念的な行で表されるなら、ifTypeのための列挙された値がメディア特有の特定の組み合わせにMIBsを写像するその特定の組み合わせに必要です。 その上、まだ、MIBスタックのすべての副層の関係について説明するメソッドの不足があります。
An associated problem is that of upward and downward multiplexing of
関連する問題は上向きの、そして、下向きのマルチプレクシングのものです。
McCloghrie & Kastenholz [Page 4] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[4ページ]RFC1573はグループ発展1994年1月に連結します。
the sub-layers. An example of upward multiplexing is MLP (Multi- Link-Procedure) which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer(s) above. An example of downward multiplexing would be several instances of PPP, each framed within a separate X.25 virtual circuit, all of which run over one fractional T1 channel, concurrently with other uses of the T1 link. The current MIB structure does not allow for these sorts of relationships to be described.
副層。 上向きのマルチプレクシングに関する例は単一のポイントツーポイント接続として上で副層に見えることによっていくつかのシリアル・ラインの上に負荷分割法を供給するMLP(マルチLinkの手順)です。 下向きのマルチプレクシングに関する例はPPPのいくつかのインスタンスでしょう、別々のX.25仮想の回路の中に縁どられたそれぞれ、T1リンクの他の用途で断片的なT1が同時にどれが稼働するかに関する1つ以上にチャネルを開設するすべて。 MIBが構造化する電流は、これらの種類の関係が説明されるのを許容しません。
3.1.3. Virtual Circuits
3.1.3. 仮想の回路
Several of the sub-layers for which media-specific MIB modules have been defined are connection oriented (e.g., Frame Relay, X.25). Experience has shown that each effort to define such a MIB module revisits the question of whether separate conceptual rows in the ifTable are needed for each virtual circuit. Most, if not all, of these efforts to date have decided to have all virtual circuits reference a single conceptual row in the ifTable.
メディア特有のMIBモジュールが定義された副層の数個は適応する接続(例えば、Frame Relay、X.25)です。 経験は、そのようなMIBモジュールを定義する各取り組みがifTableの別々の概念的な行がそれぞれの仮想の回路に必要であるかどうかに関する質問を再訪させるのを示しました。 これまでのこれらの取り組みの大部分(すべてでなくても)は、すべての仮想の回路にifTableでただ一つの概念的な行に参照をつけさせると決めました。
3.1.4. Bit, Character, and Fixed-Length Interfaces
3.1.4. ビット、キャラクター、および固定長インタフェース
RS-232 is an example of a character-oriented sub-layer over which (e.g., through use of PPP) IP datagrams can be sent. Due to the packet-based nature of many of the objects in the ifTable, experience has shown that it is not appropriate to have a character-oriented sub-layer represented by a (whole) conceptual row in the ifTable.
RS-232は(例えば、PPPの使用による)IPデータグラムを送ることができるキャラクタ指向の副層に関する例です。 ifTableのオブジェクトの多くのパケットベースの本質のため、経験は、ifTableの(全体)の概念的な行でキャラクタ指向の副層を表させるのが適切でないことを示しました。
Experience has also shown that it is sometimes desirable to have some management information for bit-oriented interfaces, which are similarly difficult to represent by a (whole) conceptual row in the ifTable. For example, to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data.
また、経験は、ビット指向のインタフェースのための何らかの経営情報を持っているのが時々望ましいのを示しました。インタフェースはifTableの(全体)の概念的な行で表すのは同様に難しいです。 例えば何人かのチャンネルだけがパケットベースのデータを運ぶDS1回路のチャンネルを管理するために。
A further complication is that some subnetwork technologies transmit data in fixed length transmission units. One example of such a technology is cell relay, and in particular Asynchronous Transfer Mode (ATM), which transmits data in fixed-length cells. Representing such a interface as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit (e.g., the size of a cell).
さらなる複雑さはいくつかのサブネットワーク技術が固定長トランスミッション単位のデータを送るということです。 そのような技術に関する1つの例が、セルリレーと、特にAsynchronous Transfer Mode(ATM)です。(そのAsynchronous Transfer Modeは固定長セルの中でデータを送ります)。 パケットベースのインタフェースのようなインタフェースを表すと、パケットの数とどちらかの方向への八重奏の数との関係がトランスミッションユニット(例えば、セルのサイズ)のサイズによって修理されているなら、余分なオブジェクトは作り出されます。
3.1.5. Counter Size
3.1.5. カウンタサイズ
As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, on an Ethernet, a stream of back-to-back, full-size packets will cause ifInOctets to wrap in just over 57 minutes. For a T3 line, the minimum wrap-time
ネットワークメディア増加の速度、最小の時間として32ビットのカウンタが減少を包装する。 例えば、イーサネットでは、背中合わせのフルサイズパケットの流れはちょうど57分以上後に包装へのifInOctetsを引き起こすでしょう。 T3系列、最小の包装時に
McCloghrie & Kastenholz [Page 5] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[5ページ]RFC1573はグループ発展1994年1月に連結します。
is just over 12 minutes. For FDDI, it will wrap in 5.7 minutes. For a 1-gigabit medium, the counter might wrap in as little as 34 seconds. Requiring that interfaces be polled frequently enough not to miss a counter wrap will be increasingly problematic.
12分のすぐ上あります。 FDDIに関しては、それは5.7で数分を包装するでしょう。 1ギガビットの媒体のために、カウンタは最小34で秒を包装するかもしれません。 インタフェースがカウンタ包装をなくすことができないくらいの頻繁に投票されるのが必要であるのはますます問題が多いでしょう。
3.1.6. Interface Speed
3.1.6. インタフェース速度
Network speeds are increasing. The range of ifSpeed is limited to reporting a maximum speed of (2**31)-1 bits/second, or approximately 2.2Gbs. SONET defines an OC-48 interface, which is defined at operating at 48 times 51 Mbs, which is a speed in excess of 2.4gbits. Thus, ifSpeed will be of diminishing utility over the next several years.
ネットワーク速度は上がっています。 ifSpeedの範囲は(2**31)の最高回転数に-1ビット/秒、またはおよそ2.2Gbsを報告するのに制限されます。 SonetはOC-48インタフェースを定義します。(それは、48掛ける51Mbsで作動すると定義されます)。(Mbsは2.4gbitsを超えた速度です)。 したがって、ifSpeedは次の数年間効用逓減のものになるでしょう。
3.1.7. Multicast/Broadcast Counters
3.1.7. マルチキャスト/放送カウンタ
The counters in the ifTable for packets addressed to a multicast or the broadcast address, are combined as counters of non-unicast packets. In contrast, the ifExtensions MIB [7] defines one set of counters for multicast, and a separate set for broadcast packets. With the separate counters, the original combined counters become redundant.
マルチキャストか放送演説に扱われたパケットのためのifTableのカウンタは非ユニキャストパケットを反対するように結合されています。 対照的に、ifExtensions MIB[7]はマルチキャストのための1セットのカウンタ、および放送パケットのための別々のセットを定義します。 別々のカウンタで、元の結合したカウンタは余分になります。
3.1.8. Addition of New ifType values
3.1.8. New ifType値の追加
Over time new ifType enumerated values have been needed for new interface types. With the syntax of ifType being defined in a MIB, this requires the new MIB to be re-issued in order to define the new values. In the past, re-issuing of the MIB has occurred only after several years.
新しいifTypeが列挙した時間、値が新しいインターフェース型に必要です。 ifTypeの構文がMIBで定義されている状態で、これは、新しい値を定義するために新しいMIBが再発行されるのを必要とします。 過去に、MIBの再発行は数年後にだけ起こりました。
3.1.9. ifSpecific
3.1.9. ifSpecific
The original definition of the OBJECT IDENTIFIER value of ifSpecific was not sufficently clear. As a result, different implementors have used it differently, and confusion has resulted. Some implementations have the value of ifSpecific be the OBJECT IDENTIFIER that defines the media-specific MIB, i.e., the "foo" of:
ifSpecificのOBJECT IDENTIFIER価値のオリジナルの定義はsufficentlyに明確ではありませんでした。 その結果、異なった作成者はそれを異なって使用しました、そして、混乱は結果として生じました。 いくつかの実装が、ifSpecificの値がすなわち、メディア特有のMIB、以下の"foo"を定義するOBJECT IDENTIFIERであることを持っています。
foo OBJECT IDENTIFIER ::= { transmission xxx }
foo OBJECT IDENTIFIER:、:= トランスミッションxxx
while others have it be the OBJECT IDENTIFIER of the table or entry in the appropriate media-specific MIB (e.g. fooTable or fooEntry), while still others have it be the OBJECT IDENTIFIER of the index object of the table's row, including instance identifier (e.g., fooIfIndex.ifIndex). A definition based on the latter would not be sufficient unless it also allowed for media-specific MIBs which include several tables, where each table has its own, different,
他のものにはそれがある間の適切なメディア特有のMIB(例えば、fooTableかfooEntry)のテーブルかエントリーのOBJECT IDENTIFIERになってください、それでも、他のものは、それがテーブルの行のインデックスオブジェクトのOBJECT IDENTIFIERであることを持っていますが、インスタンス識別子(例えば、fooIfIndex.ifIndex)を含んでいて。 また、各テーブルがそれ自身のものを持っている数個のテーブルを含んでいるメディア特有のMIBsを考慮しない場合、後者に基づく定義は十分でないでしょうに、異なります。
McCloghrie & Kastenholz [Page 6] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[6ページ]RFC1573はグループ発展1994年1月に連結します。
indexing.
インデックス。
3.2. Clarifications/Revisions
3.2. 明確化/改正
The following clarifications and/or revisions are proposed.
以下の明確化、そして/または、改正は提案されます。
3.2.1. Interface Numbering
3.2.1. インタフェース付番
One solution to the interface numbering problem would be to redefine ifNumber to be the largest value of ifIndex, but the utility of such an object is questionable, and such a re-definition would require ifNumber to be deprecated. Thus, an improvement would be to deprecate ifNumber and not replace it. However, the deprecation of ifNumber would require a change to that portion of ifIndex's definition which refers to ifNumber. So, since the definition of ifIndex must be changed anyway in order to solve the problem, changes to ifNumber do not benefit the solution.
そのようなオブジェクトのユーティリティは疑わしいです、そして、インタフェース付番問題への1つの解決がifIndexの最も大きい値になるようにifNumberを再定義するだろうことですが、そのような再定義はifNumberが推奨しないのを必要とするでしょう。 したがって、改良は、ifNumberを非難して、それを取り替えないだろうことです。 しかしながら、ifNumberの不賛成はifNumberについて言及するifIndexの定義のその部分への変化を必要とするでしょう。 それで、問題を解決するためにとにかくifIndexの定義を変えなければならないので、ifNumberへの変化はソリューションのためになりません。
The solution adopted in this memo is to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition. It could be argued that this is a change in the semantics of ifIndex; however, all existing implementations conform to this new definition, and in the interests of not requiring changes in existing implementations and in the many existing media-specific MIBs, it is proposed that this change does not require ifIndex to be deprecated.
このメモに採用されたソリューションは、ifIndexの値がifNumberの値以下でなければならないという要件を削除して、現在の定義があるifNumberを保有することです。 これがifIndexの意味論で変化であると主張できました。 しかしながら、すべての既存の実装がこの新しい定義に従います、そして、既存の実装と多くの既存のメディア特有のMIBsに釣り銭がいないことのために、この変化が、ifIndexが推奨しないのを必要としないよう提案されます。
This solution also results in the possibility of "holes" in the ifTable (i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous), but SNMP's GetNext (and SNMPv2's GetBulk) operation easily deals with such holes. The value of ifNumber still represents the number of conceptual rows, which increases/decreases as new interfaces are dynamically added/removed. The vital constancy requirement is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used (by a different dynamically added interface) until after the following re-initialization of the network management system. This avoids the need for a priori assignment of ifIndex values for all possible interfaces which might be added dynamically.
また、このソリューションはifTableの「穴」の可能性をもたらしますが(すなわち、ifTableの概念的な行のifIndex値は必ず隣接であるというわけではありません)、SNMPのGetNext(そして、SNMPv2のGetBulk)操作は容易にそのような穴に対処します。 ifNumberの値はまだ概念的な行の数を表しています。(ダイナミックに新しいインタフェースを加えるか、または取り除くのに従って、それは、増強するか、または減少します)。 ダイナミックにインタフェースを取り除いた後にネットワーク管理システムの以下の再初期化の後までifIndex値を再使用しないのを(異なったダイナミックに加えられたインタフェースのそばで)必要とすることによって、重大な不変性必要条件は満たされます。 これはダイナミックに加えられるかもしれないすべての可能なインタフェースとしてifIndex値の先験的な課題の必要性を避けます。
The exact meaning of a "different" interface is hard to define, and there will be gray areas. One important criterion is that a management station, not noticing that an interface has gone away and another come into existence, should not be confused when it calculates the difference between the counter values retrieved on successive polls for a particular ifIndex value. However, any firm definition in this document would likely to turn out to be inadequate. Instead, the following guidelines are offered to allow
「異なった」インタフェースの正確な意味は定義しにくいです、そして、暗い領域があるでしょう。 1つの重要な評価基準は管理局、インタフェースが遠ざかったのに気付かないで、別のものが生まれて、特定のifIndex値のための連続した投票のときに検索された対価の違いについて計算する場合混乱するべきでないということです。 しかしながら、どんな堅い定義も、不十分になるように判明するように本書ではおそらくそうするでしょう。 代わりに、以下のガイドラインを提供する、許容
McCloghrie & Kastenholz [Page 7] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[7ページ]RFC1573はグループ発展1994年1月に連結します。
implementors to choose what "different" means in their particular situation.
「異なること」が彼らの特定の状況で意味することを選ぶ作成者。
A previously-unused value of ifIndex should be assigned to a dynamically added interface if:
ifIndexの以前に未使用の値がダイナミックに加えられたインタフェースに割り当てられるべきである、:
(1) the assignment of a previously-used ifIndex value to the
interface could result in a discontinuity in the values of
ifTable counters for that value of ifIndex; or,
(1) インタフェースへの以前中古のifIndex価値の課題はifIndexのその値のためのifTableカウンタの値における不連続をもたらすかもしれません。 または
(2) an agent has no knowledge of whether the interface is the
"same" or "different" from a previous interface incarnation.
(2) エージェントには、インタフェースが前のインタフェース肉体化からの「同じである」か「異なる」であるのに関する知識が全くありません。
Because of the restriction of the value of ifIndex to be less than ifNumber, interfaces have been numbered with small integer values. This has led to the ability by humans to use the ifIndex values as (somewhat) user-friendly names for network interfaces (e.g., "interface number 3"). With the relaxation of the restriction on the value of ifIndex, there is now the possibility that ifIndex values could be assigned as very large numbers (e.g., memory addresses). Such numbers would be much less user-friendly.
ifNumberより少ないifIndexの価値の制限のために、インタフェースは小さい整数値で付番されました。 これがネットワーク・インターフェースに(いくらか)ユーザフレンドリーな名前としてifIndex値を使用する人間による能力に通じた、(例えば、「インタフェース数の3インチ)」 現在、ifIndexの値における制限の緩和と共に、非常に大きい数(例えば、メモリアドレス)としてifIndex値を割り当てることができた可能性があります。 そのような数はあまりそれほどユーザフレンドリーでないでしょう。
Therefore, this memo recommends that ifIndex values still be assigned as (relatively) small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous. (Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces.)
したがって、このメモが、ifIndex値がまだ割り当てられることを勧める、(比較的、)、わずかな整数は1時の始めを評価します、使用中の値がいかなる時も、必ず隣接であるというわけではありませんが。 (これでどの値を割り当ててあったかを覚えているのがエージェントにとって簡単になることに注意してください(ダイナミックに新しいインタフェースを加えます)。)
This proposed change introduces a new problem of its own. Previously, there usually was a simple, direct, mapping of interfaces to the physical ports on systems. This mapping would be based on the ifIndex value. However, by removing the previous restrictions on the values allowed for ifIndex, along with the interface sub-layer concept (see the following section), mapping from interfaces to physical ports becomes increasingly problematic.
この変更案はそれ自身の新しい問題を紹介します。 以前、通常、システムの上の物理的なポートへのインタフェースの簡単で、ダイレクトなマッピングがありました。このマッピングはifIndex値に基づくでしょう。 しかしながら、ifIndexのために許容された値で前の制限を取り除くことによって、インタフェース副層の概念(以下のセクションを見る)と共に、インタフェースから物理的なポートまでのマッピングはますます問題が多くなります。
To address this issue, a new object, ifName, is added to the MIB. This object contains the device's name for the interface of which the relevant entry in the ifTable is a component. For example, if a router has an interface named wan1, which is composed of PPP running over an RS-232 port, the ifName objects for the corresponding PPP and RS-232 entries in the ifTable will contain the string "wan1".
この問題を扱うために、新しいオブジェクト(ifName)はMIBに加えられます。 このオブジェクトはifTableの関連エントリーがコンポーネントであるインタフェースへのデバイスの名前を含んでいます。 例えば、ルータにRS-232ポートを中を走らせるPPPで構成されるwan1というインタフェースがあると、対応するPPPのためのifNameオブジェクトとifTableのRS-232エントリーはストリング"wan1""を含むでしょう。
3.2.2. Interface Sub-Layers
3.2.2. インタフェース副層
One possible but not recommended solution to the problem of representing multiple sub-layers would be to retain the concept of one conceptual row for all the sub-layers of an interface and have
複数の副層を表すという問題への1つの可能な、しかし、お勧めでない解決がインタフェースのすべての副層のための1つの概念的な行の概念を保有するだろうことである、有
McCloghrie & Kastenholz [Page 8] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[8ページ]RFC1573はグループ発展1994年1月に連結します。
each media-specific MIB module identify its "superior" and "subordinate" sub-layers through OBJECT IDENTIFIER "pointers". The drawbacks of this scheme are: 1) the superior/subordinate pointers are contained in the media-specific MIB modules, and thus, a manager could not learn the structure of an interface, without inspecting multiple pointers in different MIB modules; this is overly complex and only possible if the manager has knowledge of all the relevant media-specific MIB modules; 2) current MIB modules would all need to be retrofitted with these new "pointers"; 3) this scheme does not adequately address the problem of upward and downward multiplexing; and 4) enumerated values of ifType are needed for each combination of sub-layers.
それぞれのメディア特有のMIBモジュールはOBJECT IDENTIFIER「指針」を通して「優れ」て「下位」の副層を特定します。 この体系の欠点は以下の通りです。 1) 優れたか下位の指針はメディア特有のMIBモジュールで含まれました、そして、その結果、マネージャはインタフェースの構造を学ぶことができませんでした、異なったMIBモジュールで複数の指針を点検しないで。 マネージャにすべての関連メディア特有のMIBモジュールに関する知識がある場合にだけ、これは、ひどく複雑であって、可能です。 2) 現在のMIBモジュールはすべて、これらの新しい「指針」で改装される必要があるでしょう。 3)この体系は適切に上向きの、そして、下向きのマルチプレクシングのその問題を訴えません。 そして、ifTypeの4つの)列挙された値が副層の各組み合わせに必要です。
Another possible but not recommended scheme would be to retain the concept of one conceptual row for all the sub-layers of an interface and have a new separate MIB table to identify the "superior" and "subordinate" sub-layers which contain OBJECT IDENTIFIER "pointers" to media-specific MIB module(s) for each sub-layer. Effectively, one conceptual row in the ifTable would represent each combination of sub-layers between the internetwork-layer and the wire. While this scheme has fewer drawbacks, it does not support downward multiplexing, such as PPP over MLP; since MLP makes two (or more) serial lines appear to the layers above as a single physical interface, PPP over MLP should appear to the internetwork-layer as a single interface. However, this scheme would result in two (or more) conceptual rows in the ifTable and the internetwork-layer would run over both of them. This scheme also requires enumerated values of ifType for each combination of sub-layers.
別の可能な、しかし、お勧めでない体系は、インタフェースのすべての副層のための1つの概念的な行の概念を保有して、各副層のためにメディア特有のMIBモジュールにOBJECT IDENTIFIER「指針」を含む「優れ」て「下位」の副層を特定する新しい別々のMIBテーブルを持つだろうことです。 事実上、ifTableの1つの概念的な行がインターネットワーク層とワイヤの間の副層の各組み合わせを表すでしょう。 この体系には、より少ない欠点がある間、MLPの上のPPPなどの下向きのマルチプレクシングをサポートしません。 MLPが単一の物理インターフェースとして上に2個(さらに)のシリアル・ラインを層に現れさせるので、MLPの上のPPPは単一のインタフェースとしてインターネットワーク層に見えるはずです。 しかしながら、この体系はifTableの2つ(さらに)の概念的な行をもたらすでしょう、そして、インターネットワーク層はそれらの両方をひくでしょう。 また、この体系は副層の各組み合わせのためにifTypeの列挙された値を必要とします。
The solution adopted in this memo is to have an individual conceptual row in the ifTable to represent each sub-layer and have a new separate MIB table (the ifStackTable, see section 5 of this memo) to identify the "superior" and "subordinate" sub-layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable. This solution supports both upward and downward multiplexing. It also allows the IANAIfType to Media-Specific MIB mapping to identify the media-specific MIB module for each sub- layer. The new table (ifStackTable) need be referenced only to obtain information about layering. Enumerated values for ifType are required for each sub- layer only, not for combinations of them.
見てください。このメモに採用されたソリューションが各副層を表して、新しい別々のMIBテーブルを持つためにifTableに個々の概念的な行を持つことである、(ifStackTable、セクション5に関するこのメモ) INTEGER「指針」を通して「優れ」て「下位」の副層をifTableの適切な概念的な行に特定するために。 このソリューションは、両方が上向きの、そして、下向きのマルチプレクシングであるとサポートします。 また、それで、メディア特有のMIBマッピングへのIANAIfTypeはそれぞれのサブ層のためにメディア特有のMIBモジュールを特定できます。 新しいテーブル(ifStackTable)は参照をつけられなければなりませんが、レイヤリングの情報を得ます。 ifTypeのための列挙された値がそれらの組み合わせに必要であるのではなく、それぞれのサブ層だけに必要です。
However, this solution does require that the descriptions of some objects in the ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to any sub-layer (rather than only to a sub-layer immediately beneath the network layer, as at present). It also requires that some objects (specifically, ifSpeed) need to have appropriate values identified for use when a generalized definition does not apply to a
しかしながら、このソリューションが、ifTable(明確にifType、ifPhysAddress、ifInUcastPkts、およびifOutUcastPkts)のいくつかのオブジェクトの記述がどんな副層にも適用するために一般化されるのを必要とする、(むしろ、ネットワーク層のすぐ下の副層だけプレゼント、) また、それは、いくつかのオブジェクト(明確にifSpeed)が一般化された定義がaに適用されないとき使用のために特定された適切な値を必要とするのを必要とします。
McCloghrie & Kastenholz [Page 9] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[9ページ]RFC1573はグループ発展1994年1月に連結します。
particular sub-layer.
特定の副層。
In addition, this adopted solution makes no requirement that a device, in which a sub-layer is instrumented by a conceptual row of the ifTable, be aware of whether an internetwork protocol runs on top of (i.e., at some layer above) that sub-layer. In fact, the counters of packets received on an interface are defined as counting the number "delivered to a higher-layer protocol". This meaning of "higher-layer" includes:
さらに、この採用されたソリューションは副層がどれであるかにifTableの概念的な行によって器具を取り付けられたデバイスがインターネットワークプロトコルがその(すなわち、上の何らかの層の)副層の上で稼働するかどうかを意識しているという要件を全く作りません。 事実上、インタフェースに受け取られたパケットのカウンタは「上位層プロトコルに提供された」数を数えると定義されます。 「より高い層」のこの意味は:
(1) Delivery to a forwarding module which accepts
packets/frames/octets and forwards them on at the same
protocol layer. For example, for the purposes of this
definition, the forwarding module of a MAC-layer bridge is
considered as a "higher-layer" to the MAC-layer of each port
on the bridge.
(1) /が同じプロトコル層で/八重奏を縁どっていて、それらを進めるパケットを受け入れる推進モジュールへの配送。 例えば、この定義の目的のために、MAC-層のブリッジの推進モジュールはブリッジの上のそれぞれのポートのMAC-層への「より高い層」であるとみなされます。
(2) Delivery to a higher sub-layer within a interface stack. For
example, for the purposes of this definition, if a PPP module
operated directly over a serial interface, the PPP module
would be considered the higher sub-layer to the serial
interface.
(2) インタフェーススタックの中の、より高い副層への配送。 例えば、この定義の目的のために、PPPモジュールがシリアルインタフェースの上で直営するなら、PPPモジュールはシリアルインタフェースへの、より高い副層であると考えられるでしょうに。
(3) Delivery to a higher protocol layer which does not do packet
forwarding for sub-layers that are "at the top of" the
interface stack. For example, for the purposes of this
definition, the local IP module would be considered the
higher layer to a SLIP serial interface.
(3) 副層のためのパケット推進をしないより高いプロトコル層への配送、「」 インタフェースの先端では、積み重ねてください。 例えば、この定義の目的のために、ローカルアイピーモジュールはSLIPシリアルインタフェースへの、より高い層であると考えられるでしょう。
Similarly, for output, the counters of packets transmitted out an interface are defined as counting the number "that higher-level protocols requested to be transmitted". This meaning of "higher- layer" includes:
同様に、出力において、インタフェースから伝えられたパケットのカウンタは「上位レベル・プロトコルは伝えられるよう要求した」数を数えると定義されます。 「より高い層」のこの意味は:
(1) A forwarding module, at the same protocol layer, which
transmits packets/frames/octets that were received on an
different interface. For example, for the purposes of this
definition, the forwarding module of a MAC-layer bridge is
considered as a "higher-layer" to the MAC-layer of each port
on the bridge.
(1) 同じプロトコル層の推進モジュール。(それは、異なったインタフェースで受けられたパケット/フレーム/八重奏を伝えます)。 例えば、この定義の目的のために、MAC-層のブリッジの推進モジュールはブリッジの上のそれぞれのポートのMAC-層への「より高い層」であるとみなされます。
(2) The next higher sub-layer within an interface stack. For
example, for the purposes of this definition, if a PPP module
operated directly over a serial interface, the PPP module
would be a "higher layer" to the serial interface.
(2) インタフェーススタックの中の次の、より高い副層。 例えば、この定義の目的のために、PPPモジュールがシリアルインタフェースの上で直営するなら、PPPモジュールはシリアルインタフェースへの「より高い層」でしょうに。
McCloghrie & Kastenholz [Page 10] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[10ページ]RFC1573はグループ発展1994年1月に連結します。
(3) For sub-layers that are "at the top of" the interface stack,
a higher element in the network protocol stack. For example,
for the purposes of this definition, the local IP module
would be considered the higher layer to an Ethernet
interface.
副層のための(3)、「」 インタフェーススタックの先端では、ネットワーク・プロトコルにおける、より高い要素に、積み重ねてください。 例えば、この定義の目的のために、ローカルアイピーモジュールはイーサネットインタフェースへの、より高い層であると考えられるでしょう。
3.2.3. Guidance on Defining Sub-layers
3.2.3. 副層を定義するときの指導
The designer of a media-specific MIB must decide whether to divide the interface into sub-layers, and if so, how to make the divisions. The following guidance is offered to assist the media-specific MIB designer in these decisions.
メディア特有のMIBのデザイナーは、インタフェースを副層に分割するかどうかと、そうだとすれば、どのように分割をするかを決めなければなりません。 メディア特有のMIBデザイナーをこれらの決定に助けるために以下の指導を提供します。
In general, the number of entries in the ifTable should be kept to the minimum required for network management. In particular, a group of related interfaces should be treated as a single interface with one entry in the ifTable providing that:
一般に、ifTableのエントリーの数はネットワークマネージメントに必要である最小限に保たれるべきです。 特に、関連するインタフェースのグループがifTableの1つのエントリーとの単一のインタフェースとして扱われるべきである、:
(1) None of the group of interfaces performs multiplexing for any
other interface in the agent,
(1) インタフェースのグループのいずれもエージェントでいかなる他のインタフェースにもマルチプレクシングを実行しません。
(2) There is a meaningful and useful way for all of the ifTable's
information (e.g., the counters, and the status variables),
and all of the ifTable's capabilities (e.g., write access to
ifAdminStatus), to apply to the group of interfaces as a
whole.
(2) 全体でインタフェースのグループに適用するために、ifTableの情報のすべて(例えば、カウンタ、および状態変数)、およびifTableの能力のすべて(例えば、ifAdminStatusへのアクセスを書く)のための重要で役に立つ方法があります。
Under these circumstances, there should be one entry in the ifTable for such a group of interfaces, and any internal structure which needs to be represented to network management should be captured in a MIB module specific to the particular type of interface.
こういう事情ですから、1つのエントリーがインタフェースのそのようなグループのためのifTableにあるべきです、そして、特定のタイプのインタフェースに特定のMIBモジュールでネットワークマネージメントに表される必要があるどんな内部の構造も得るべきです。
Note that application of bullet 2 above to the ifTable's ifType object requires that there is a meaningful media-specific MIB and a meaningful ifType value which apply to the group of interfaces as a whole. For example, it is not appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as a single ifTable entry when the media- specific MIBs and the ifType values for HDLC and RS-232 are separate (rather than combined).
ifTypeが全体でインタフェースのグループに適用される重要なメディア特有のMIBと重要なifType値があるのが必要であることを反対させるifTableのものに上で弾丸2のその塗布に注意してください。 メディアの特定のMIBsとHDLCとRS-232のためのifType値が別々であるときに(結合されているよりむしろ)、例えば、単一のifTableエントリーとしてHDLC副層とRS-232副層を扱うのは適切ではありません。
Note that the sub-layers of an interface on one device will sometimes be different to the sub-layers of the interconnected interface of another device. A simple example of this is a frame-relay DTE interface which connects to a frameRelayService interface, where the DTE interface has a different ifType value and media-specific MIB to the DCE interface.
1台のデバイスの上のインタフェースの副層が時々別のデバイスのインタコネクトされたインタフェースの副層に異なるようになることに注意してください。 この簡単な例はDTEインタフェースが異なったifType値とメディア特有のMIBをDCEインタフェースまで持っているframeRelayServiceインタフェースに接続するフレームリレーDTEインタフェースです。
Also note that a media-specific MIB may mandate that a particular
また、メディア特有のMIBがそのa事項を強制するかもしれないことに注意してください。
McCloghrie & Kastenholz [Page 11] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[11ページ]RFC1573はグループ発展1994年1月に連結します。
ifTable counter does not apply and that its value must always be 0, signifying that the applicable event can not and does not occur for that type of interface; for example, ifInMulticastPkts and ifOutMulticastPkts on an interface type which has no multicast capability. In other circumstances, an agent must not always return 0 for any counter just because its implementation is incapable of detecting occurrences of the particular event; instead, it must return a noSuchName/noSuchObject error/exception when queried for the counter, even if this prevents the implementation from complying with the relevant MODULE-COMPLIANCE macro.
カウンタが適用しないで、起こらないで、適切な出来事がそのタイプのインタフェースに起こることができないのを意味であるので0、値がいつもそうしなければならないifTable。 例えば、インタフェースのifInMulticastPktsとifOutMulticastPktsはタイプします(マルチキャスト能力が全くありません)。 他の事情では、実現が特定の出来事の発生を検出できるだけではないので、エージェントはいつもどんなカウンタにも0を返さなければならないというわけではありません。 代わりに、カウンタに質問されると、noSuchName/noSuchObject誤り/例外を返さなければなりません、これが、実現が関連MODULE-COMPLIANCEマクロに従うのを防いでも。
These guidelines are just that - guidelines. The designer of a media-specific MIB is free to lay out the MIB in whatever SMI conformant manner is desired. However, in so doing, the media- specific MIB MUST completely specify the sub-layering model used for the MIB, and provide the assumptions, reasoning, and rationale used to develop that model.
これらのガイドラインはまさしくそれです--ガイドライン。 メディア特有のMIBのデザイナーは望まれているどんなSMI conformant方法でも自由にMIBを広げることができます。 しかしながら、そうすることにおけるメディアの特定のMIB MUSTはMIBに使用されるサブレイヤリングモデルを完全に指定して、そのモデルを開発するのに使用される仮定、推理、および原理を提供します。
3.2.4. Virtual Circuits
3.2.4. 仮想のサーキット
This memo strongly recommends that connection-oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual rows, especially those which have considerable redundant information. (Note, as a comparison, that connection-less sub-layers do not have conceptual rows for each remote address.) There may, however, be circumstances under which it is appropriate for a virtual circuit of a connection- oriented sub-layer to have its own conceptual row in the ifTable; an example of this might be PPP over an X.25 virtual circuit. The MIB in section 6 of this memo supports such circumstances.
このメモは、接続指向の副層がそれぞれの仮想のサーキットへのifTableに概念的な列を持たないことを強く勧めます。 これは概念的な列、特にかなりの余分な情報を持っているものの増殖を避けます。 (比較として、コネクションレスな副層にはそれぞれのリモートアドレスのための概念的な列がないことに注意してください。) しかしながら、接続指向の副層の仮想のサーキットがifTableにそれ自身の概念的な列を持っているのが、適切である事情があるかもしれません。 この例はX.25の仮想のサーキットの上のPPPであるかもしれません。 このメモのセクション6のMIBはそのような事情を支持します。
If a media-specific MIB wishes to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for this decision in the media-specific MIB's specification.
メディア特有のMIBがifTableでそれぞれの仮想のサーキットにエントリーを割り当てたいなら、MIBデザイナーはメディア特有のMIBの仕様に基づくこの決定のために原理を提示しなければなりません。
3.2.5. Bit, Character, and Fixed-Length Interfaces
3.2.5. ビット、キャラクター、および固定長インタフェース
About half the objects in the ifTable are applicable to every type of interface: packet-oriented, character-oriented, and bit-oriented. Of the other half, two are applicable to both character-oriented and packet-oriented interfaces, and the rest are applicable only to packet-oriented interfaces. Thus, while it is desirable for consistency to be able to represent any/all types of interfaces in the ifTable, it is not possible to implement the full ifTable for bit- and character-oriented sub-layers.
ifTableの物のおよそ半分がすべてのタイプのインタフェースに適切です: パケット指向で、キャラクタ指向で、ビット指向です。 もう片方の半分では、2はキャラクタ指向のものと同様にパケット指向のインタフェースに適切です、そして、残りはパケット指向のインタフェースだけに適切です。 したがって、一貫性がifTableにすべてがタイプするインタフェースのどんな/も表すことができるのが、望ましいのですが、ビットとキャラクタ指向の副層のために完全なifTableを実行するのは可能ではありません。
One possible but not recommended solution to this problem would be to split the ifTable into two (or more) new MIB tables, one of which
どれでこの問題のお勧めでない唯一の解決がifTableを分割することであることが2個(さらに)の新しいMIBテーブル、1つに可能な1つ
McCloghrie & Kastenholz [Page 12] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[12ページ]RFC1573はグループ発展1994年1月に連結します。
would contain objects that are relevant only to packet-oriented interfaces (e.g., PPP), and another that may be used by all interfaces. This is highly undesirable since it would require changes in every agent implementing the ifTable (i.e., just about every existing SNMP agent).
パケット指向のインタフェース(例えば、PPP)だけに関連している物、およびすべてのインタフェースによって使用されるかもしれない別のものを含んでいるでしょう。 ifTable(すなわち、まさしくすべての既存のSNMPエージェントに関する)を実行するすべてのエージェントに釣り銭がいるでしょう、したがって、これは非常に望ましくありません。
The solution adopted in this memo builds upon the fact that compliance statements in SNMPv2 (in contrast to SNMPv1) refer to object groups, where object groups are explicitly defined by listing the objects they contain. Thus, in SNMPv2, multiple compliance statements can be specified, one for all interfaces and additional ones for specific types of interfaces. The separate compliance statements can be based on separate object groups, where the object group for all interfaces can contain only those objects from the ifTable which are appropriate for every type of interfaces. Using this solution, every sub-layer can have its own conceptual row in the ifTable.
このメモに採用された解決策はSNMPv2(SNMPv1と対照して)での承諾声明が物のグループがそれらが含む物を記載することによって明らかに定義される物のグループを参照するという事実を当てにします。 したがって、SNMPv2では、複数の承諾声明を指定できて、すべてのための1つは、特定のタイプのインタフェースへのインタフェースと追加ものです。 別々の承諾声明は別々の物のグループに基づくことができます。そこでは、すべてのインタフェースへの物のグループがすべてのタイプのインタフェースに、適切なifTableからのそれらの物しか含むことができません。 この解決策を使用して、あらゆる副層がifTableにそれ自身の概念的な列を持つことができます。
Thus, section 6 of this memo contains definitions of the objects of
the existing 'interfaces' group of MIB-II, in a manner which is both
SNMPv2-compliant and semantically-equivalent to the existing MIB-II
definitions. With equivalent semantics, and with the BER ("on the
wire") encodings unchanged, these definitions retain the same OBJECT
IDENTIFIER values as assigned by MIB-II. Thus, in general, no
rewrite of existing agents which conform to MIB-II and the
ifExtensions MIB is required.
したがって、このメモのセクション6はMIB-IIの既存の'インタフェース'グループの物の定義を含みます、既存のMIB-II定義にSNMPv2対応であって、かつ意味的に同等な方法で。 同等な意味論、およびBER(「ワイヤ」の)encodingsが変わりがない状態で、これらの定義はMIB-IIによって割り当てられるのと同じOBJECT IDENTIFIER値を保有します。 このようにして、そして、一般に、MIB-IIとifExtensions MIBに従う既存のエージェントの書き直しは全く必要ではありません。
In addition, this memo defines several object groups for the purposes of defining which objects apply to which types of interface:
さらに、このメモはどの物がどのタイプのインタフェースに適用されるかを定義する目的のためにいくつかの物のグループを定義します:
(1) the ifGeneralGroup. This group contains those objects
applicable to all types of network interfaces, including
bit-oriented interfaces.
(1) ifGeneralGroup。 このグループはビット指向のインタフェースを含むすべてのタイプのネットワーク・インターフェースに適切なそれらの物を含みます。
(2) the ifPacketGroup. This group contains those objects
applicable to packet-oriented network interfaces.
(2) ifPacketGroup。 このグループはパケット指向のネットワーク・インターフェースに適切なそれらの物を含みます。
(3) the ifFixedLengthGroup. This group contains the objects
applicable not only to character-oriented interfaces, such as
RS-232, but also to those subnetwork technologies, such as
cell-relay/ATM, which transmit data in fixed length
transmission units. As well as the octet counters, there are
also a few other counters (e.g., the error counters) which
are useful for this type of interface, but are currently
defined as being packet-oriented. To accommodate this, the
definitions of these counters are generalized to apply to
character-oriented interfaces and fixed-length-transmission
interfaces.
(3) ifFixedLengthGroup。 このグループはRS-232などのキャラクタ指向のインタフェースだけではなく、それらのサブネットワーク技術に適切な物を含みます、セルリレー/ATMなどのように。(ATMは固定長トランスミッション単位のデータを送ります)。 また、八重奏カウンタと同様に、このタイプのインタフェースの役に立ちますが、現在パケット指向であると定義される他のいくつかのカウンタ(例えば、誤りカウンタ)があります。 これを収容するなら、これらのカウンタの定義は、キャラクタ指向のインタフェースと固定長さの送信インタフェースに適用するために一般化されます。
McCloghrie & Kastenholz [Page 13] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[13ページ]RFC1573はグループ発展1994年1月に連結します。
It should be noted that the octet counters in the ifTable aggregate octet counts for unicast and non-unicast packets into a single octet counter per direction (received/transmitted). Thus, with the above definition of fixed-length-transmission interfaces, where such interfaces which support non-unicast packets, separate counts of unicast and multicast/broadcast transmissions can only be maintained in a media-specific MIB module.
ifTableの八重奏カウンタが指示(受け取るか、または伝える)あたり1台の単一の八重奏カウンタへのユニキャストと非ユニキャストパケットのための八重奏カウントに集められることに注意されるべきです。 したがって、固定長さの送信インタフェースの上の定義で、メディア特有のMIBモジュールでユニキャストとマルチキャスト/放送送信の別々のカウントを維持できるだけです。(そこでは、そのようなものがそのサポート非ユニキャストパケットを連結します)。
3.2.6. Counter Size
3.2.6. カウンタサイズ
Two approaches to addressing the shrinking minimum counter-wrap time problem were evaluated. Counters could be scaled, for example, ifInOctets could be changed to count received octets in, e.g., 1024 byte blocks. Alternatively, the size of the counter could be increased.
その縮まっている最小のカウンタ包装時間問題を訴えることへの2つのアプローチが評価されました。 カウンタをスケーリングできました、例えば、ifInOctetsは例えば、1024年のバイトの容認された八重奏を数えるために変えられたブロックであるかもしれません。 あるいはまた、カウンタのサイズは増加できました。
Scaling the counters was rejected. While it provides acceptable performance at high count rates, at low rates it suffers. If there is little traffic on an interface, there might be a significant interval before enough counts occur to cause a counter to be incremented. Traffic would then appear to be very bursty, leading to incorrect conclusions of the network's performance.
カウンタをスケーリングするのは拒絶されました。 高い計数率で許容性能を提供しますが、低率では、それに苦しみます。 交通がインタフェースにほとんどなければ、十分なカウントがカウンタが増加されることを引き起こすために起こる前に重要な間隔があるかもしれません。 そして、ネットワークの性能の不正確な結末に通じて、交通はまさしくそのburstyであるように見えるでしょう。
The alternative, which this memo adopts, is to provide expanded, 64 bit, counters. These counters are provided in new "high capacity" groups,
代替手段(このメモは採用する)は、提供するのが広がって、64に噛み付いたということであり、反対します。 新しい「高容量」グループにこれらのカウンタを提供します。
The old, 32-bit, counters have not been deprecated. The 64-bit counters are to be used only when the 32-bit counters do not provide enough capacity; that is, the 32 bit counters could wrap too fast.
古くて、32ビットのカウンタは非難されていません。 32ビットのカウンタが十分な容量を提供しないときだけ、64ビットのカウンタは使用されていることになっています。 すなわち、カウンタがあまりに速く包装できた32ビット。
For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be used. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be used and 64-bit octet counters MUST be used. For interfaces that operate at 650,000,000 bits/second or faster, both 64-bit packet counters AND 64-bit octet counters MUST be used.
2000万で作動するインタフェースのために、(2000万)bpsか、より少なくて、32ビットのバイトとパケットカウンタを使用しなければなりません。 2000万より速く6億5000万ビット/秒よりビット/2番目で、遅い状態で作動するインタフェースのために、32ビットのパケットカウンタを使用しなければなりません、そして、64ビットの八重奏カウンタを使用しなければなりません。 6億5000万ビット/秒か、より速く作動するインタフェースのために、64ビットのパケットカウンタと64ビットの八重奏カウンタの両方を使用しなければなりません。
These speed steps were chosen as reasonable compromises based on the following:
これらの速度ステップは以下に基づく合理的な妥協として選ばれました:
(1) The cost of maintaining 64-bit counters is relatively high,
so minimizing the number of agents which must support them is
desirable. Common interfaces (such as Ethernet) should not
require them.
(1) 64ビットのカウンタを維持する費用が比較的高いので、彼らを支持しなければならないエージェントの数を最小にするのは望ましいです。 一般的なインタフェース(イーサネットなどの)はそれらを必要とするべきではありません。
McCloghrie & Kastenholz [Page 14] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[14ページ]RFC1573はグループ発展1994年1月に連結します。
(2) 64-bit counters are a new feature, introduced in SNMPv2. It
is reasonable to expect that support for them will be spotty
for the immediate future. Thus, we wish to limit them to as
few systems as possible. This, in effect, means that 64-bit
counters should be limited to higher speed interfaces.
Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
fairly wide-spread so it seems reasonable to not require 64-
bit counters for these interfaces.
(2) 64ビットのカウンタはSNMPv2で導入された新機能です。 それらのサポートが即座の未来にまだらになると予想するのは妥当です。 したがって、できるだけわずかしかそれらをシステムに制限したいと思いません。 有効なこれは、64ビットのカウンタが、より高い速度インタフェースに制限されるべきであることを意味します。 イーサネット(1000万ビーピーエス)とToken Ring(1600万ビーピーエス)がかなり広範囲であるので、64の噛み付いているカウンタをこれらのインタフェースに必要としないのは妥当に思えます。
(3) The 32-bit octet counters will wrap in the following times,
for the following interfaces (when transmitting maximum-sized
packets back-to-back):
(3) カウンタが以下の時代に以下のために包装する32ビットの八重奏が連結する、(最大サイズのパケットを伝える、背中合わせである、)、:
- Ethernet: 57 minutes,
- イーサネット: 57分
- 16 megabit Token Ring: 36 minutes,
- 16メガビットToken Ring: 36分
- A US T3 line (45 megabits): 12 minutes,
- US T3線(45のメガビット): 12分
- FDDI: 5.7 minutes
- FDDI: 5.7分
(4) The 32-bit packet counters wraps in about 57 minutes when
64-byte packets are transmitted back-to-back on a 650,000,000
bit/second link.
(4) 32ビットのパケットは64バイトのパケットが6億5000万ビット/秒のリンクの上に背中合わせの状態で伝えられるおよそ57分後に機密を打ち返します。
As an aside, a 1-terabit (1,000 gigabits) link will cause a
64 bit octet counter to wrap in just under 5 years.
Conversely, an 81,000,000 terabit/second link is required to
cause a 64-bit counter to wrap in 30 minutes. We believe
that, while technology rapidly marches forward, this link
speed will not be achieved for at least several years,
leaving sufficient time to evaluate the introduction of 96
bit counters.
余談として、1テラビット(1,000のギガビット)のリンクで、64ビットの八重奏カウンタはちょうど5年未満を中に包装するでしょう。 逆に、テラビット/第2リンクが64ビットを引き起こしていなければならない8100万は30分後に包装に反対します。 私たちは、このリンク速度が少なくとも数年間達成されないと技術が急速に前進している間、信じています、96ビットの挿入を評価できるくらいの時間をカウンタに発って。
When 64-bit counters are in use, the 32-bit counters MUST still be available. They will report the low 32-bits of the associated 64-bit count (e.g., ifInOctets will report the least significant 32 bits of ifHCInOctets). This enhances inter-operability with existing implementations at a very minimal cost to agents.
64ビットのカウンタが使用中であるときに、32ビットのカウンタはまだ利用可能でなければなりません。 彼らは関連64ビットのカウントの低32ビットを報告するでしょう(例えば、ifInOctetsはifHCInOctetsの最も重要でない32ビットを報告するでしょう)。 これはエージェントへの非常に最小量の費用における既存の実現で相互運用性を高めます。
The new "high capacity" groups are:
新しい「高容量」グループは以下の通りです。
(1) the ifHCFixedLengthGroup for character-oriented/fixed-length
interfaces, and the ifHCPacketGroup for packet-based
interfaces; both of these groups include 64 bit counters for
octets, and
(1) キャラクタ指向の、または、固定長さのインタフェースへのifHCFixedLengthGroup、およびパケットベースのインタフェースへのifHCPacketGroup。 そしてこれらのグループの両方が八重奏のための64ビットのカウンタを含んでいる。
McCloghrie & Kastenholz [Page 15] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[15ページ]RFC1573はグループ発展1994年1月に連結します。
(2) the ifVHCPacketGroup for packet-based interfaces; this group
includes 64 bit counters for octets and packets.
(2) パケットベースのインタフェースへのifVHCPacketGroup。 このグループは八重奏とパケットのための64ビットのカウンタを含んでいます。
3.2.7. Interface Speed
3.2.7. インタフェース速度
In order to deal with increasing interface speeds, we have added an ifHighSpeed object.
増加するインタフェース速度に対処するために、私たちはifHighSpeed物を加えました。
This object reports the speed of the interface in 1,000,000 (1 million) bits/second units. Thus, the true speed of the interface will be the value reported by this object, plus or minus 500,000 bits/second.
この物は100万(100万)ビット/の2番目のユニットのインタフェースの速度を報告します。 したがって、インタフェースの真の速度はこの物、または、50万ビット/秒およびを引いて報告された値になるでしょう。
Other alternatives considered were:
考えられた他の代替手段は以下の通りでした。
(1) Making the interface speed a 64-bit gauge. This was rejected
since the current SMI does not allow such a syntax.
(1) インタフェースを作って、64ビットのゲージを促進してください。 現在のSMIがそのような構文を許容しないので、これは拒絶されました。
Furthermore, even if 64-bit gauges were available, their use
would require additional complexity in agents due to an
increased requirement for 64-bit operations.
その上、64ビットのゲージが利用可能であったとしても、彼らの使用は64ビット演算のための増加する要件のためエージェントで追加複雑さを必要とするでしょうに。
(2) We also considered making "high-32 bit" and "low-32-bit"
objects which, when combined, would be a 64-bit value. This
simply seemed overly complex for what we are trying to do.
(2) また、私たちは、「高値-32ビット」と「低32ビット」を結合されると64ビットの値である物にすると考えました。 これは単に私たちがしようとしていることにひどく複雑に見えました。
Furthermore, a full 64-bits of precision does not seem
necessary. The value of ifHighSpeed will be the only report
of interface speed for interfaces that are faster than
4,294,967,295 bits per second. At this speed, the
granularity of ifHighSpeed will be 1,000,000 bits per second,
thus the error will be 1/4294, or about 0.02%. This seems
reasonable.
その上、精度の完全な64ビットは必要に見えません。 ifHighSpeedの値は42億9496万7295のbpsより速いインタフェースへのインタフェース速度の唯一のレポートになるでしょう。 この速度では、ifHighSpeedの粒状が100万のbpsになる、その結果、誤りは、1/4294か、およそ0.02%になるでしょう。 これは妥当に思えます。
(3) Adding a "scale" object, which would define the units which
ifSpeed's value is.
(3) 「スケール」物を加えること。(それは、ifSpeedの値がそうであるユニットを定義するでしょう)。
This would require two additional objects; one for the
scaling object, and one to replace the current ifSpeed. This
later object is required since the semantics of ifSpeed would
be significantly altered, and manager stations which do not
understand the new semantics would be confused.
これは2個の追加物を必要とするでしょう。 スケーリング物、および現在のifSpeedを取り替える1のためのもの。 ifSpeedの意味論はかなり変更されるでしょう、そして、新しい意味論を理解していないマネージャステーションが混乱するでしょう、したがって、この後の物が必要です。
3.2.8. Multicast/Broadcast Counters
3.2.8. マルチキャスト/放送カウンタ
To avoid the redundancy of counting all non-unicast packets as well as having individual multicast and broadcast packet counters, we deprecate the use of the non-unicast counters, which can be derived
私たちがよく個々のマルチキャストと放送パケットカウンタのように引き出すことができる非ユニキャストカウンタの使用を非難しながらすべての非ユニキャストパケットを数える冗長を避けるために
McCloghrie & Kastenholz [Page 16] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[16ページ]RFC1573はグループ発展1994年1月に連結します。
from the values of the others.
他のものの値から。
For the output broadcast and multicast counters defined in RFC 1229, their definitions varied slightly from the packet counters in the ifTable, in that they did not count errors/discarded packets. To align the definitions better, the old counters are deprecated and replaced by new definitions. Counters with 64 bits of range are also needed, as explained above.
RFC1229で定義された出力放送とマルチキャストカウンタに関しては、彼らの定義はifTableのパケットカウンタからわずかに変わりました、彼らが誤り/捨てられたパケットを数えなかったので。 定義をよりよく並べるために、古いカウンタを新しい定義に非難して、取り替えます。 また、範囲の64ビットがあるカウンタが上で説明されるように必要です。
3.2.9. Trap Enable
3.2.9. 罠は可能にします。
In the multi-layer interface model, each sub-layer for which there is an entry in the ifTable can generate linkUp/Down Traps. Since interface state changes would tend to propagate through the interface (from top to bottom, or bottom to top), it is likely that several traps would be generated for each linkUp/Down occurrence.
マルチ層のインタフェースモデルでは、エントリーがifTableにある各副層はlinkUp/下にTrapsを発生させることができます。 界面準位変化は、インタフェース(付ける下部、または先端から下部までの)を通して伝播する傾向があるでしょう、したがって、いくつかの罠がそれぞれのlinkUp/下に発生単位で発生しそうでしょう。
It is desirable to provide a mechanism for manager stations to control the generation of these traps. To this end, the ifLinkUpDownTrapEnable object has been added. This object allows managers to limit generation of traps to just the sub-layers of interest.
マネージャステーションがこれらの罠の世代を制御するようにメカニズムを提供するのは望ましいです。 このために、ifLinkUpDownTrapEnable物は加えられます。 この物で、マネージャは罠の世代をまさしく興味がある副層に制限できます。
The default setting should limit the number of traps generated to one per interface per linkUp/Down event. Furthermore, it seems that the conditions that cause these state changes that are of most interest to network managers occur at the lowest level of an interface stack. Therefore we specify that by default, only the lowest sub-layer of the interface generate traps.
既定の設定はlinkUp/下に出来事単位で1インタフェースあたり1つに発生する罠の数を制限するはずです。 その上、これらのほとんどおもしろい州の変化をネットワークマネージャに引き起こす状態がインタフェーススタックの最も低いレベルで現れるように思えます。 したがって、私たちは、デフォルトで、インタフェースの最も低い副層だけが罠を発生させると指定します。
3.2.10. Addition of New ifType values
3.2.10. New ifType値の添加
The syntax of ifType is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention, IANAifType, which can be re-specified (with additional values) without issuing a new version of this document. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new ifType values. Thus, this document defines two MIB modules: one to define the MIB for the 'interfaces' group, and a second to define the first version of the IANAifType textual convention. The latter will be periodically re-issued by the IANA.
原文のコンベンションになるようにifTypeの構文を変えます、列挙された整数値が現在原文のコンベンション、IANAifType(このドキュメントの新しいバージョンを発行しないで、再指定できます(加算値がある))で定義されるように。 ISOCの機関の一つで(IANA)はすべてのインターネット番号の課題に責任があります、様々なSNMP関連の数、および明確に新しいifType値を含んでいて。 したがって、このドキュメントは2つのMIBモジュールを定義します: 'インタフェース'グループのためにMIBを定義する1、IANAifTypeの原文のコンベンションの最初のバージョンを定義する2番目。 後者は定期的にIANAによって再発行されるでしょう。
3.2.11. InterfaceIndex Textual Convention
3.2.11. InterfaceIndexの原文のコンベンション
A new textual convention, InterfaceIndex, has been defined. This textual convention "contains" all of the semantics of the ifIndex object. This allows other mib modules to easily import the semantics
新しい原文のコンベンション(InterfaceIndex)は定義されました。 この原文のコンベンションはifIndex物の意味論のすべてを「含みます」。 これで、他のmibモジュールは容易に意味論を意味できます。
McCloghrie & Kastenholz [Page 17] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[17ページ]RFC1573はグループ発展1994年1月に連結します。
of ifIndex.
ifIndexについて。
3.2.12. IfAdminStatus and IfOperStatus
3.2.12. IfAdminStatusとIfOperStatus
A new state has been added to ifOperStatus: dormant. This state indicates that the relevant interface is not actually in a condition to pass packets (i.e., up) but is in a "pending" state, waiting for some external event. For "on-demand" interfaces, this new state identifies the situation where the interface is waiting for events to place it in the up state. Examples of such events might be:
新しい状態はifOperStatusに加えられます: 眠る。 この州は、関連インタフェースがパケット(すなわち、上がっている)を通過する実際に状態でありませんが、「未定」の状態にあるのを示します、いくつかの外部の出来事を待っていて。 「要求次第」のインタフェースに関しては、この新しい州はそれを置くインタフェースが出来事を待っている上がるのが述べる状況を特定します。 そのような出来事に関する例は以下の通りです。
(1) having packets to transmit before establishing a connection
to a remote system.
(1) リモートシステムに取引関係を築く前に伝えるパケットを持っていること。
(2) having a remote system establish a connection to the
interface (e.g., dialing up to a slip-server).
(2) リモートシステムを持っていて、インタフェース(例えば、メモ用紙サーバまでのダイヤルする)に取引関係を築いてください。
The down state now has two meanings, depending on the value of ifAdminStatus.
下に州には、ifAdminStatusの値によって、現在、2つの意味があります。
(1) If ifAdminStatus is not down and ifOperStatus is down, then a
fault condition is presumed to exist on the interface.
(1) ifAdminStatusが下がっていなくて、ifOperStatusが下がっているなら、欠点状態はあえてインタフェースに存在しています。
(2) If ifAdminStatus is down, then ifOperStatus will normally
also be down, i.e., there is not (necessarily) a fault
condition on the interface.
また、(2) ifAdminStatusが下がっていると通常、ifOperStatusも下がる、すなわち、(必ず)欠点状態がインタフェースにありません。
Note that when ifAdminStatus transitions to down, ifOperStatus will normally also transition to down. In this situation, it is possible that ifOperStatus's transition will not occur immediately, but rather after a small time lag to complete certain operations before going "down"; for example, it might need to finish transmitting a packet. If a manager station finds that ifAdminStatus is down and ifOperStatus is not down for a particular interface, the manager station should wait a short while and check again. If the condition still exists only then should it raise an error indication. Naturally, it should also ensure that ifLastChange has not changed during this interval.
また、ifAdminStatusがダウンするように移行するとき通常、ifOperStatusがダウンするように移行することに注意してください。 この状況で、ifOperStatusの変遷がすぐに、しかし、むしろ小さいタイムラグの後に現在の“down"の前で、ある操作を完了するために起こらないのは、可能です。 例えば、それは、パケットを伝え終える必要があるかもしれません。 マネージャステーションが、ifAdminStatusが下がっているのがわかって、特定のインタフェースにifOperStatusがないなら、マネージャステーションは、少しの間待っていて、再びチェックするべきです。 状態がまだ存在しているなら、それは誤り表示を上げるだけであるべきです。 また、当然、それは、ifLastChangeがこの間隔の間変化していないのを確実にします。
Whenever an interface table entry is created (usually as a result of system initialization), the relevant instance of ifAdminStatus is set to down, and presumably ifOperStatus will also be down.
インタフェーステーブルエントリーが作成される(通常システム初期化の結果、)ときはいつも、ifAdminStatusの関連例がダウンするように設定されて、また、おそらく、ifOperStatusも下がるでしょう。
An interface may be enabled in two ways: either as a result of explicit management action (e.g., setting ifAdminStatus to up) or as a result of the managed system's initialization process. When ifAdminStatus changes to the up state, the related ifOperStatus should do one of the following:
インタフェースは2つの方法で可能にされるかもしれません: 明白な管理活動(例えば、ifAdminStatusに上昇するように設定する)の結果、管理されたシステムの初期化の結果、処理してください。 上がることへの変化が述べるifAdminStatus、関連するifOperStatusがそうするべきであるとき、以下の1つをしてください:
McCloghrie & Kastenholz [Page 18] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[18ページ]RFC1573はグループ発展1994年1月に連結します。
(1) Change to the up state if and only if the interface is able
to send and receive packets.
そして、(1) 上の状態に変えてください、インタフェースがパケットを送って、受けることができる場合にだけ。
(2) Change to the dormant state if and only if the interface is
found to be operable, but the interface is waiting for other,
external, events to occur before it can transmit or receive
packets. Presumably when the expected events occur, the
interface will then transition to the up state.
(2) 休止状態の状態に変化してください、単に、インタフェースは手術可能であることがわかっていますが、インタフェースはもう一方、外部(パケットを伝えるか、または受けることができる前に起こる出来事)を待っています。 おそらく、予想された出来事が起こると、インタフェースは上がることへの変遷が述べるその時が起こるでしょう。
(3) Remain in the down state if an error or other fault condition
is detected on the interface.
(3) 誤りか他の欠点状態がインタフェースに検出されるなら、下に州に残ってください。
(4) Change to the unknown state if, for some reason, the state of
the interface can not be ascertained.
(4) ある理由で、インタフェースの状態を確かめることができないかどうかを未知の状態に変えてください。
(5) Change to the testing state if some test(s) must be performed
on the interface. Presumably after completion of the test,
the interface's state will change to up, dormant, or down, as
appropriate.
(5) インタフェースに何らかのテストを実行しなければならないかどうかをテスト状態に変えてください。 おそらくテストの完成の後に、州が変化するインタフェースは、上がる、眠る、または下がっていて、適切です。
3.2.13. Traps
3.2.13. 罠
The exact definition of when linkUp and linkDown traps are generated, has been changed to reflect the changes to ifAdminStatus and ifOperStatus.
いつlinkUpとlinkDown罠の正確な定義を発生して、ifAdminStatusとifOperStatusへの変化を反映するために変えたか。
LinkUp and linkDown traps are generated just after ifOperStatus leaves, or just before it enters, the down state, respectively. The wording of the conditions under which a linkDown trap is generated was explicitly chosen to allow a node with only one interface to transmit the linkDown trap before that interface goes down.
ifOperStatusがいなくなるか、ちょうど以前入って、または下であるのが状態になったすぐ後にLinkUpとlinkDown罠はそれぞれ発生しています。 そのインタフェースが落ちる前にlinkDown罠が発生する状態の言葉遣いは、1つのインタフェースだけがあるノードがlinkDown罠を伝えるのを許容するために明らかに選ばれました。
Operational experience seems to indicate that manager stations are most concerned with an interface being in the down state and the fact that this state may indicate a failure. It seemed most useful to instrument either transitions into/out of the up state or the down state.
運用経験はマネージャステーションは下に状態にあるインタフェースとこの州が失敗を示すかもしれないという事実に最も関係があるのを示すように思えます。 それは上がるのからの/への変遷が述べる器具か下に状態の最も役に立つように見えました。
Instrumenting transitions into or out of the up state has the drawback that an on-demand interface might have many transitions between up and dormant, leading to many linkUp traps and no linkDown traps. Furthermore, if a node's only interface is the on-demand interface, then a transition to dormant will entail generation of a trap, necessitating bringing the link to the up state (and a linkUp trap)!!
状態の中、または、上の状態から変遷に器具を取り付けるのにおいて、要求次第のインタフェースが間に上がって眠っていた状態で移行して、多くのlinkUp罠にもかかわらず、どんなlinkDown罠にも通じないことで多くにするかもしれない欠点があります。 その上、眠っていることへの変遷はノードの唯一のインタフェースが要求次第のインタフェースであるなら罠の世代を伴うでしょう、状態(そして、linkUp罠)を上がることへのリンクに持って来るのを必要として!
On the other hand, instrumenting transitions into or out of the down state has the advantages:
他方では、州には、下に中、または、下であるから変遷に器具を取り付けて、利点があります:
McCloghrie & Kastenholz [Page 19] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[19ページ]RFC1573はグループ発展1994年1月に連結します。
(1) A transition into the down state will occur when an error is
detected on an interface. Error conditions are presumably of
great interest to network managers.
(1) 誤りがインタフェースに検出されるとき、下に状態への変遷は起こるでしょう。 おそらく、エラー条件はすごくネットワークマネージャにおもしろいです。
(2) Departing the down state generally indicates that the
interface is going to either up or dormant, both of which are
considered "healthy" states.
(2) 一般に、どれが「健康な」州であるとともに考えられるかについて下に状態を退職するのは、インタフェースが上がるか、または眠っていた状態でそうするのを示します。
Furthermore, it is believed that generarating traps on transitions into or out of the down state is generally consistent with current usage and interpretation of these traps by manager stations.
その上、一般に、変遷のときに状態の中、または、下に状態から罠をgeneraratingするのがマネージャステーションによるこれらの罠の現在の用法と解釈と一致していると信じられています。
Therefore, this memo defines that it is the transitions into/out of the down state which generate traps.
したがって、このメモはそれを定義します。下であるのからの/への変遷が、どれが罠を発生させるかを述べるということです。
Obviously, if a failure condition is present on a node with a single interface, the linkDown trap will probably not be succesfully transmitted since the interface through which it must be transmitted has failed.
明らかに、失敗状態がノードに単一のインタフェースについて存在していると、それを伝えなければならないインタフェースが失敗したので、linkDown罠はたぶんsuccesfullyに伝えられないでしょう。
3.2.14. ifSpecific
3.2.14. ifSpecific
The current definition of ifSpecific is not explicit enough. The only definition that can both be made explicit and can cover all the useful situations (see section 3.1.9) is to have ifSpecific be the most general value for the media-specific MIB module (the first example given section in 3.1.9). This effectively makes it redundant because it contains no more information than is provided by ifType. For this reason, ifSpecific has been deprecated.
ifSpecificの現在の定義は十分明白ではありません。 明白に作ることができて、すべての役に立つ状況をカバーできる(セクション3.1.9を見ます)唯一の定義がifSpecificがメディア特有のMIBモジュールのための最も一般的な値であることを持つことである、(中でセクションに出された最初の例、3.1、.9、) これで、ifTypeによって提供されるより多くの情報を含んでいないので、事実上、それは余分になります。 この理由で、ifSpecificは非難されました。
3.3. Media-Specific MIB Applicability
3.3. メディア特有のMIBの適用性
The exact use and semantics of many objects in this MIB are open to some interpretation. This is a result of the generic nature of this MIB. It is not always possible to come up with specific, unambiguous, text that covers all cases and yet preserve the generic nature of the MIB.
このMIBの多くの物の正確な使用と意味論は何らかの解釈に開かれています。 これはこのMIBの一般的な自然の結果です。 すべてのケースをカバーする特定の、そして、明白なテキストを思いつきますが、MIBの一般的な自然を保持するのはいつも可能であるというわけではありません。
Therefore, it is incumbent upon a media-specific MIB designer to, wherever necessary, clarify the use of the objects in this MIB with respect to the media-specific MIB.
したがって、メディア特有のMIBデザイナーでは、どこでも、必要であるところでメディア特有のMIBに関してこのMIBにおける物の使用をはっきりさせるのは義務です。
Specific areas of clarification include:
明確化の特定の領域は:
Layering Model
The media-specific MIB designer MUST completely and
unambiguously specify the layering model used. Each
individual sub-layer must be identified.
Modelを層にして、メディア特有のMIBデザイナーは完全に明白に使用されるレイヤリングモデルを指定しなければなりません。 それぞれの個々の副層を特定しなければなりません。
McCloghrie & Kastenholz [Page 20] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[20ページ]RFC1573はグループ発展1994年1月に連結します。
Virtual Circuits
The media-specific MIB designer MUST specify whether virtual
circuits are assigned entries in the ifTable or not. If they
are, compelling rationale must be presented.
メディア特有のMIBデザイナーの仮想のCircuitsは、エントリーがifTableで仮想のサーキットに割り当てられるかどうか指定しなければなりません。 それらがそうなら、無視できない原理を提示しなければなりません。
ifTestTable
The media-specific MIB designer MUST specify the
applicability of the ifTestTable.
メディア特有のMIBデザイナーのifTestTableはifTestTableの適用性を指定しなければなりません。
ifRcvAddressTable
The media-specific MIB designer MUST specify the
applicability of the ifRcvAddressTable.
メディア特有のMIBデザイナーのifRcvAddressTableはifRcvAddressTableの適用性を指定しなければなりません。
ifType
For each of the ifType values to which the media-specific MIB
applies, it must specify the mapping of ifType values to
media-specific MIB module(s) and instances of MIB objects
within those modules.
それぞれそれが、メディア特有のMIBが適用すると指定しなければならないifType値のifType Forはそれらのモジュールの中でMIBのメディア特有のMIBモジュールと例に反対しますifTypeに関するマッピングが、評価する。
However, wherever this interface MIB is specific in the semantics, DESCRIPTION, or applicability of objects, the media-specific MIB designer MUST NOT change said semantics, DESCRIPTION, or applicability.
しかしながら、どこでも、このインタフェースMIBが物の意味論、記述、または適用性で特定であるところでは、メディア特有のMIBデザイナーが前述の意味論、記述、または適用性を変えてはいけません。
4. Overview
4. 概観
This MIB consists of 5 tables:
このMIBは5個のテーブルから成ります:
ifTable
This table is the ifTable from MIB-II.
ifTable ThisテーブルはMIB-IIからのifTableです。
ifXTable
This table contains objects that have been added to the
Interface MIB as a result of the Interface Evolution effort,
or replacements for objects of the original, MIB-II, ifTable
that were deprecated because the semantics of said objects
have significantly changed. This table also contains objects
that were previously in the ifExtnsTable.
ifXTable ThisテーブルはInterface Evolutionの努力の結果、Interface MIB、またはオリジナルの物との交換に加えられる物を含んでいます、MIB-II、前述の物の意味論がかなり変化したので非難されたifTable。 また、このテーブルは以前に、ifExtnsTableにあった物を含んでいます。
ifStackTable
This table contains objects that define the relationships
among the sub-layers of an interface.
ifStackTable Thisテーブルはインタフェースの副層の中で関係を定義する物を含んでいます。
ifTestTable
This table contains objects that are used to perform tests on
interfaces. This table is a generic table. The designers of
media-specific MIBs must define exactly how this table
applies to their specific MIB.
ifTestTable Thisテーブルはインタフェースのテストを実行するのに使用される物を含んでいます。 このテーブルは一般的なテーブルです。 メディア特有のMIBsのデザイナーはこのテーブルがちょうどどう彼らの特定のMIBに適用されるかを定義しなければなりません。
McCloghrie & Kastenholz [Page 21] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[21ページ]RFC1573はグループ発展1994年1月に連結します。
This table replaces the interface test table defined in
RFC1229 [7]. The significant change is the replacement of
the ifExtnsTestCommunity (and ifExtnsTestContext which would
also have been required for SNMPv2) and ifExtnsTestRequestId
objects, by the new ifTestId, ifTestStatus, and ifTestOwner
objects.
このテーブルはRFC1229[7]で定義されたインタフェーステストテーブルを取り替えます。 著しい変化は、ifExtnsTestCommunity(そして、また、SNMPv2に必要であったifExtnsTestContext)の交換と新しいifTestId、ifTestStatus、およびifTestOwner物によるifExtnsTestRequestId物です。
ifRcvAddressTable
This table contains objects that are used to define the
media-level addresses which this interface will receive.
This table is a generic table. The designers of media-
specific MIBs must define exactly how this table applies to
their specific MIB.
ifRcvAddressTable Thisテーブルはこのインタフェースが受け取るメディアレベルアドレスを定義するのに使用される物を含んでいます。 このテーブルは一般的なテーブルです。 メディアの特定のMIBsのデザイナーはこのテーブルがちょうどどう彼らの特定のMIBに適用されるかを定義しなければなりません。
5. IANAifType Definition
5. IANAifType定義
IANAifType-MIB DEFINITIONS ::= BEGIN
IANAifType-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
SNMPv2-Tcからの原文のコンベンションのSNMPv2-SMIからモジュールアイデンティティ、オブジェクト・タイプを輸入します。
ianaifType MODULE-IDENTITY
LAST-UPDATED "9311082155Z"
ORGANIZATION "IANA"
CONTACT-INFO
ianaifTypeモジュールアイデンティティは"9311082155Z"組織"IANA"コンタクトインフォメーションをアップデートしました。
" Internet Assigned Numbers Authority
「インターネット規定番号権威」
Postal: USC/Information Sciences Institute
4676 Admiralty Way, Marina del Rey, CA 90292
郵便: マリナデルレイ、カリフォルニア USC/情報Sciences Institute4676海軍本部Way、90292
Tel: +1 310 822 1511
E-Mail: iana@isi.edu"
DESCRIPTION
"The MIB module which defines the IANAifType textual
convention, and thus the enumerated values of the
ifType object defined in MIB-II's ifTable."
::= { mib-2 30 }
Tel: +1 1511年の310 822メール: " iana@isi.edu "記述は「IIのMIB-ものでは、ifTableを定義IANAifTypeの原文のコンベンションを定義するMIBモジュール、およびその結果、ifTypeの列挙された値が反対するしました」。 ::= mib-2 30
IANAifType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used as the syntax of the ifType
object in the (updated) definition of MIB-II's
ifTable.
IANAifType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このデータ型はifType物の構文としてMIB-IIのifTableの(アップデートします)定義に使用されます」。
McCloghrie & Kastenholz [Page 22] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[22ページ]RFC1573はグループ発展1994年1月に連結します。
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
新たに割り当てられた値の添加があるこの原文のコンベンションの定義が定期的にIANAによって発行されて、コネがAssigned民数記RFCであるかそれのある派生物がインターネットNetwork Management数の課題への詳細です。 (IANAに連絡することによって、最新のアレンジメントを得ることができます。)
Requests for new values should be made to IANA via
email (iana@isi.edu).
メール( iana@isi.edu )で新しい値を求める要求をIANAにするべきです。
The relationship between the assignment of ifType
values and of OIDs to particular media-specific MIBs
is solely the purview of IANA and is subject to change
without notice. Quite often, a media-specific MIB's
OID-subtree assignment within MIB-II's 'transmission'
subtree will be the same as its ifType value.
However, in some circumstances this will not be the
case, and implementors must not pre-assume any
specific relationship between ifType values and
transmission subtree OIDs."
SYNTAX INTEGER {
other(1), -- none of the following
regular1822(2),
hdh1822(3),
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6),
iso88023Csmacd(7),
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
starLan(11),
proteon10Mbit(12),
proteon80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18), -- DS1/E1 (RFC 1406)
e1(19), -- obsolete
basicISDN(20),
primaryISDN(21),
propPointToPointSerial(22), -- proprietary serial
ppp(23),
softwareLoopback(24),
eon(25), -- CLNP over IP (RFC 1070)
ethernet3Mbit(26),
特定のメディア特有のMIBsへのifType値とOIDsの課題の間の関係は、唯一IANAの範囲であり、予告なしで変化を被りやすいです。 かなりしばしば、MIB-IIの'トランスミッション'下位木の中のメディア特有のMIBのOID-下位木課題はifTypeが評価するのと同じになるでしょう。 「しかしながら、いくつかの事情では、これはそうにならないでしょう、そして、作成者はifType値とトランスミッション下位木OIDsとの少しの特定の関係もあらかじめ仮定してはいけません。」 SYNTAX INTEGER、もう一方(1)--以下のregular1822(2)のどんな、hdh1822(3)、ddnX25(4)、rfc877x25(5)、ethernetCsmacd(6)、iso88023Csmacd(7)、iso88024TokenBus(8)、iso88025TokenRing(9)、iso88026Man(10)、starLan(11)、proteon10Mbit(12)、proteon80Mbit(13)、hyperchannel(14)、fddi(15)、lapb(16)、sdlc(17)、ds1(18)でない; 1DS1/E(RFC1406)のe1(19)--IP(RFC1070)ethernet3Mbit(26)の上でbasicISDN(20)、primaryISDN(21)、propPointToPointSerial(22)--独占連続のppp(23)、softwareLoopback(24)、累代(25)--CLNPを時代遅れにしてください。
McCloghrie & Kastenholz [Page 23] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[23ページ]RFC1573はグループ発展1994年1月に連結します。
nsip(27), -- XNS over IP
slip(28), -- generic SLIP
ultra(29), -- ULTRA technologies
ds3(30), -- T-3
sip(31), -- SMDS
frameRelay(32), -- DTE only
rs232(33),
para(34), -- parallel-port
arcnet(35), -- arcnet
arcnetPlus(36), -- arcnet plus
atm(37), -- ATM cells
miox25(38),
sonet(39), -- SONET or SDH
x25ple(40),
iso88022llc(41),
localTalk(42),
smdsDxi(43),
frameRelayService(44), -- Frame relay DCE
v35(45),
hssi(46),
hippi(47),
modem(48), -- Generic modem
aal5(49), -- AAL5 over ATM
sonetPath(50),
sonetVT(51),
smdsIcip(52), -- SMDS InterCarrier Interface
propVirtual(53), -- proprietary virtual/internal
propMultiplexor(54) -- proprietary multiplexing
}
nsip(27)--IPメモ用紙(28)の上のXNS--一般的なSLIP超(29)--ULTRA技術ds3(30)--T-3は(31)をちびちび飲んで、--SMDS frameRelay(32)--DTEはrs232(33)にすぎません、パラ(34)--パラレルポートarcnet(35)、--arcnet arcnetPlus(36)--arcnetと気圧(37); ATMセルmiox25(38)、SonetかSDH x25ple(40)、iso88022llc(41)、localTalk(42)、smdsDxi(43)、frameRelayService(44)--フレームリレーDCE v35(45)、hssi(46)、hippi(47)、モデム(48)--一般的なモデムaal5(49)の、そして、--ATM sonetPath(50)、sonetVT(51)、smdsIcip(52)の上のAAL5--SMDS InterCarrier Interface propVirtual(53)(独占仮想の、または、内部のpropMultiplexor(54))独占であるsonet(39)、マルチプレクシング
END
終わり
6. Interfaces Group Definitions
6. グループ定義を連結します。
IF-MIB DEFINITIONS ::= BEGIN
-、MIB、定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
Integer32, TimeTicks,
NOTIFICATION-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString,
PhysAddress, TruthValue, RowStatus,
AutonomousType, TestAndIncr FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
IANAifType FROM IANAifType-MIB
interfaces FROM RFC-1213;
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Counter32、Gauge32、Integer32、TimeTicks、NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION、DisplayString、PhysAddress、TruthValue、RowStatus、AutonomousType、TestAndIncr FROM SNMPv2-TC MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF IANAifType FROM IANAifType-MIBはFROM RFC-1213を連結します。
McCloghrie & Kastenholz [Page 24] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[24ページ]RFC1573はグループ発展1994年1月に連結します。
ifMIB MODULE-IDENTITY
LAST-UPDATED "9311082155Z"
ORGANIZATION "IETF Interfaces MIB Working Group"
CONTACT-INFO
ifMIBモジュールアイデンティティ最終更新日の"9311082155Z"組織「IETFインタフェースMIB作業部会」コンタクトインフォメーション
" Keith McCloghrie
「キースMcCloghrie」
Postal: Hughes LAN Systems
1225 Charleston Road, Mountain View, CA 94043
郵便: ヒューズLANシステム1225チャールストン道路、マウンテンビュー、カリフォルニア 94043
Tel: +1 415 966 7934
E-Mail: kzm@hls.com
Tel: +1 7934年の415 966メール: kzm@hls.com
Frank Kastenholz
フランクKastenholz
Postal: FTP Software
2 High Street, North Andover, MA 01845
郵便: FTP Software2のHigh通り、ノースアンドーバー、MA 01845
Tel: +1 508 685 4000
E-Mail: kasten@ftp.com"
DESCRIPTION
"The MIB module to describe generic objects for
network interface sub-layers. This MIB is an updated
version of MIB-II's ifTable, and incorporates the
extensions defined in RFC 1229."
::= { mib-2 31 }
Tel: +1 4000年の508 685メール: " kasten@ftp.com "記述、「ネットワーク・インターフェース副層のために一般的な物について説明するMIBモジュール。」 「このMIBはMIB-IIのifTableのアップデートされたバージョンであり、RFC1229で定義された拡大を取り入れます。」 ::= mib-2 31
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
ifMIBObjects物の識別子:、:= ifMIB1
-- OwnerString has the same semantics as used in RFC 1271
-- OwnerStringには、RFC1271で同じくらい中古の同じ意味論があります。
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"This data type is used to model an administratively
assigned name of the owner of a resource. This
information is taken from the NVT ASCII character set.
It is suggested that this name contain one or more of
the following: ASCII form of the manager station's
transport address, management station name (e.g.,
domain name), network management personnel's name,
location, or phone number. In some cases the agent
itself will be the owner of an entry. In these cases,
this string shall be set to a string starting with
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
OwnerString:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"255a"STATUSの現在の記述、「このデータ型はリソースの所有者の行政上割り当てられた名前をモデル化するのに使用されます」。 NVT ASCII文字の組からこの情報を取ります。 この名前が以下の1つ以上を含むことが提案されます: ネットワークマネージメント人員のマネージャステーションの輸送アドレス、管理局名(例えば、ドメイン名)、名前、位置、または電話番号のASCIIフォーム。 いくつかの場合、エージェント自身はエントリーの所有者になるでしょう。 「これらの場合では、このストリングは'エージェント'から始まるストリングに設定されるものとします。」 構文八重奏ストリング(サイズ(0 .255))
McCloghrie & Kastenholz [Page 25] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[25ページ]RFC1573はグループ発展1994年1月に連結します。
-- InterfaceIndex contains the semantics of ifIndex and -- should be used for any objects defined on other mib -- modules that need these semantics.
-- そして、InterfaceIndexがifIndexの意味論を含んでいる、--もう一方mibで定義されたどんな物にも使用されるべきです--これらの意味論を必要とするモジュール
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface
or interface sub-layer in the managed system. It is
recommended that values are assigned contiguously
starting from 1. The value for each interface sub-
layer must remain constant at least from one re-
initialization of the entity's network management
system to the next re-initialization."
SYNTAX Integer32
InterfaceIndex:、:= 「管理されたシステムのそれぞれのインタフェースかインタフェース副層あたりゼロよりユニークな値で、すばらしい」TEXTUAL-CONVENTION DISPLAY-ヒント「d」STATUS現在の記述。 近接して1から始めて、値が割り当てられるのは、お勧めです。 「それぞれのインタフェースサブ層のための値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」 構文Integer32
ifNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their
current state) present on this system."
::= { interfaces 1 }
「ネットワーク・インターフェース(彼らの現状にかかわらず)の数はこのシステムの上に示す」ifNumber OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= インタフェース1
-- the Interfaces table
-- Interfacesテーブル
-- The Interfaces table contains information on the entity's -- interfaces. Each sub-layer below the internetwork-layer -- of a network interface is considered to be an interface.
-- Interfacesテーブルは実体の情報を含んでいます--インタフェース。 ネットワーク・インターフェースのインターネットワーク層の下の各副層はそうです。インタフェースであると考えられます。
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries
is given by the value of ifNumber."
::= { interfaces 2 }
「Aはインタフェースエントリーについて記載する」ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「ifNumberの値でエントリーの数を与えます。」 ::= インタフェース2
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable
ifEntry OBJECT-TYPE SYNTAX IfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「適切な状態で経営情報を含むエントリー」です。
McCloghrie & Kastenholz [Page 26] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[26ページ]RFC1573はグループ発展1994年1月に連結します。
to a particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
「特定のインタフェース。」 ifIndexに索引をつけてください:、:= ifTable1
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex,
ifDescr DisplayString,
ifType IANAifType,
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, -- deprecated
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, -- deprecated
ifSpecific OBJECT IDENTIFIER -- deprecated
}
IfEntry:、:= 系列{ ifIndex InterfaceIndex、ifDescr DisplayString、ifType IANAifType、ifMtu Integer32、ifSpeed Gauge32、ifPhysAddress PhysAddress、ifAdminStatus整数、ifOperStatus整数、ifLastChange TimeTicks、ifInOctets Counter32; IfInUcastPkts Counter32、ifInNUcastPkts Counter32--推奨しないifInDiscards Counter32、ifInErrors Counter32、ifInUnknownProtos Counter32、ifOutOctets Counter32、ifOutUcastPkts Counter32(ifOutNUcastPkts Counter32(推奨しないifOutDiscards Counter32、ifOutErrors Counter32、ifOutQLen Gauge32))はifSpecific OBJECT IDENTIFIERを非難しました--非難されます; }
ifIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each
interface. It is recommended that values are assigned
contiguously starting from 1. The value for each
interface sub-layer must remain constant at least from
one re-initialization of the entity's network
management system to the next re-initialization."
::= { ifEntry 1 }
「各インタフェースあたりゼロよりユニークな値で、すばらしい」ifIndex OBJECT-TYPE SYNTAX InterfaceIndexマックス-ACCESS書き込み禁止STATUS現在の記述。 近接して1から始めて、値が割り当てられるのは、お勧めです。 「それぞれのインタフェース副層のための値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」 ::= ifEntry1
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
ifDescr OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .255))マックス-ACCESS書き込み禁止STATUS海流
McCloghrie & Kastenholz [Page 27] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[27ページ]RFC1573はグループ発展1994年1月に連結します。
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of the
manufacturer, the product name and the version of the
interface hardware/software."
::= { ifEntry 2 }
記述、「インタフェースの情報を含む原文のストリング。」 「このストリングはメーカーの名前、製品名、およびインタフェースハードウェア/ソフトウェアのバージョンを含んでいるはずです。」 ::= ifEntry2
ifType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of interface. Additional values for ifType
are assigned by the Internet Assigned Numbers
Authority (IANA), through updating the syntax of the
IANAifType textual convention."
::= { ifEntry 3 }
ifType OBJECT-TYPE SYNTAX IANAifTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースのタイプ。」 「ifTypeのための加算値はインターネットAssigned民数記Authority(IANA)によって割り当てられます、IANAifTypeの原文のコンベンションの構文をアップデートすることで。」 ::= ifEntry3
ifMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The size of the largest packet which can be
sent/received on the interface, specified in octets.
For interfaces that are used for transmitting network
datagrams, this is the size of the largest network
datagram that can be sent on the interface."
::= { ifEntry 4 }
ifMtu OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「八重奏で指定されたインタフェースに送るか、または受け取ることができる中で最も大きいパケットのサイズ。」 「ネットワークデータグラムを送るのに使用されるインタフェースに関して、これはインタフェースで送ることができる中で最も大きいネットワークデータグラムのサイズです。」 ::= ifEntry4
ifSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in
bits per second. For interfaces which do not vary in
bandwidth or for those where no accurate estimation
can be made, this object should contain the nominal
bandwidth. If the bandwidth of the interface is
greater than the maximum value reportable by this
object then this object should report its maximum
value (4,294,967,295) and ifHighSpeed must be used to
report the interace's speed. For a sub-layer which
has no concept of bandwidth, this object should be
zero."
::= { ifEntry 5 }
ifSpeed OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「bpsにおけるインタフェースの現在の帯域幅の見積り。」 帯域幅で異ならないインタフェースかどんな正確な見積りもすることができないところのそれらに関しては、この物は呼び帯域幅を含むはずです。 インタフェースの帯域幅が最大値報告可能よりこの物で大きいなら、この物は、interaceの速度を報告するのにその最大値(4,294,967,295)とifHighSpeedを使用しなければならないと報告するはずです。 「帯域幅の概念を全く持っていない副層のために、この物はゼロであるべきです。」 ::= ifEntry5
McCloghrie & Kastenholz [Page 28] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[28ページ]RFC1573はグループ発展1994年1月に連結します。
ifPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface's address at its protocol sub-layer.
The interface's media-specific MIB must define the bit
and byte ordering and format of the value contained by
this object. For interfaces which do not have such an
address (e.g., a serial line), this object should
contain an octet string of zero length."
::= { ifEntry 6 }
ifPhysAddress OBJECT-TYPE SYNTAX PhysAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「プロトコル副層のインタフェースのアドレス。」 インタフェースのメディア特有のMIBはこの物によって含まれた価値のビット、バイト順、および書式を定義しなければなりません。 「そのようなアドレス(例えば、シリアル・ライン)を持っていないインタフェースに関して、この物はゼロ・レングスの八重奏ストリングを含むはずです。」 ::= ifEntry6
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3)
state indicates that no operational packets can be
passed. When a managed system initializes, all
interfaces start with ifAdminStatus in the down(2)
state. As a result of either explicit management
action or per configuration information retained by
the managed system, ifAdminStatus is then changed to
either the up(1) or testing(3) states (or remains in
the down(2) state)."
::= { ifEntry 7 }
ifAdminStatus OBJECT-TYPE SYNTAX INTEGERはいくつかのパケット下に(2)、テスト(3)を通過する準備ができている(1)にモードをテストします。マックス-ACCESSは「インタフェースの必要な状態」をSTATUSの現在の記述に読書して書きます。 テスト(3)州は、どんな操作上のパケットも通過できないのを示します。 いつ、管理されたシステムが初期化するか、すべてのインタフェースが下に(2)状態でifAdminStatusから始まります。 「そして、明白な管理活動の結果、管理されたシステムによって保有された設定情報に従って、ifAdminStatusは上がるのに(1)かテスト(3)が述べる(または、下に(2)州では、残っています)変わります。」 ::= ifEntry7
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3), -- in some test mode
unknown(4), -- status can not be determined
-- for some reason.
dormant(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets
can be passed. If ifAdminStatus is down(2) then
ifOperStatus OBJECT-TYPE SYNTAX INTEGERの{(1)を上げてください--(2)でパケットを通過する準備ができています、何らかのテスト・モード未知(4)における(3)をテストして、状態は決定できません--. ある理由で眠っている(5)}というマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースの現在の操作上の状態。」 テスト(3)州は、どんな操作上のパケットも通過できないのを示します。 ifAdminStatusが(2) その時下がっているなら
McCloghrie & Kastenholz [Page 29] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[29ページ]RFC1573はグループ発展1994年1月に連結します。
ifOperStatus should be down(2). If ifAdminStatus is
changed to up(1) then ifOperStatus should change to
up(1) if the interface is ready to transmit and
receive network traffic; it should change to
dormant(5) if the interface is waiting for external
actions (such as a serial line waiting for an
incomming connection); it should remain in the down(2)
state if and only if there is a fault that prevents if
from going to the up(1) state."
::= { ifEntry 8 }
ifOperStatusは下(2)であるべきである。 ifAdminStatusがそうなら、インタフェースが送受信する準備ができているなら(1)で(1) ifOperStatusが変化するはずであるその時に変えて、交通をネットワークでつないでください。 それは、インタフェースが外部の動き(incomming接続を待つシリアル・ラインなどの)を待っているかどうかを眠っている(5)に変えるべきです。 「それが下に(2)州に残るべきである、行くのからそれが上(1)状態に防ぐ故障が単にある、」 ::= ifEntry8
ifLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the interface
entered its current operational state. If the current
state was entered prior to the last re-initialization
of the local network management subsystem, then this
object contains a zero value."
::= { ifEntry 9 }
ifLastChange OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースが現在の操作上の状態に入った時のsysUpTimeの値。」 「現状が企業内情報通信網管理サブシステムの最後の再初期化の前に入られたなら、この物はaゼロ値を含んでいます。」 ::= ifEntry9
ifInOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
including framing characters."
::= { ifEntry 10 }
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースで受けた」ifInOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ifEntry10
ifInUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were not addressed to a
multicast or broadcast address at this sub-layer."
::= { ifEntry 11 }
ifInUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く届けられたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストか放送演説に記述されませんでした)。 ::= ifEntry11
ifInNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of packets, delivered by this sub-layer to
ifInNUcastPkts OBJECT-TYPE SYNTAX Counter32マックス-ACCESS書き込み禁止STATUSが記述を非難した、「この副層で届けられたパケットの数、」
McCloghrie & Kastenholz [Page 30] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[30ページ]RFC1573はグループ発展1994年1月に連結します。
a higher (sub-)layer, which were addressed to a
multicast or broadcast address at this sub-layer.
This object is deprecated in favour of
ifInMulticastPkts and ifInBroadcastPkts."
::= { ifEntry 12 }
高さ、(サブ、)、層。(その層はこの副層のマルチキャストか放送演説に扱われました)。 「このオブジェクトはifInMulticastPktsとifInBroadcastPktsを支持して推奨しないです。」 ::= ifEntry12
ifInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of inbound packets which were chosen to be
discarded even though no errors had been detected to
prevent their being deliverable to a higher-layer
protocol. One possible reason for discarding such a
packet could be to free up buffer space."
::= { ifEntry 13 }
ifInDiscards OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「誤りが全くそれらの存在提出物をより高い層に防ぐために検出されていませんでしたが、捨てられるために選ばれた本国行きのパケットの数は議定書を作ります」。 「そのようなパケットを捨てる1つの可能な理由はバッファ領域を開けることであることができました。」 ::= ifEntry13
ifInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from
being deliverable to a higher-layer protocol. For
character-oriented or fixed-length interfaces, the
number of inbound transmission units that contained
errors preventing them from being deliverable to a
higher-layer protocol."
::= { ifEntry 14 }
「パケット指向のインタフェース、それらが提出物であることを上位層プロトコルに防ぐ誤りを含んだ本国行きのパケットの数」のためのifInErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「キャラクタ指向の、または、固定長さのインタフェースに関して、それらが提出物であることをより高い層に防ぐ誤りを含んだ本国行きのトランスミッションユニットの数は議定書を作ります。」 ::= ifEntry14
ifInUnknownProtos OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of packets
received via the interface which were discarded
because of an unknown or unsupported protocol. For
character-oriented or fixed-length interfaces which
support protocol multiplexing the number of
transmission units received via the interface which
were discarded because of an unknown or unsupported
protocol. For any interface which does not support
protocol multiplexing, this counter will always be 0."
::= { ifEntry 15 }
「パケット指向のインタフェース、未知の、または、サポートされないプロトコルのために捨てられたインタフェースを通して受け取られたパケットの数」のためのifInUnknownProtos OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 キャラクタ指向の、または、固定長さのインタフェースに関しては、どのサポートがトランスミッションユニットの数を多重送信しながら議定書を作るかは未知の、または、サポートされないプロトコルのために捨てられたインタフェースを通して受信されました。 「このカウンタはいつもプロトコルマルチプレクシングをサポートしないどんなインタフェースに関する0にもなるでしょう。」 ::= ifEntry15
McCloghrie & Kastenholz [Page 31] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[31ページ]RFC1573はグループ発展1994年1月に連結します。
ifOutOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters."
::= { ifEntry 16 }
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースから伝えた」ifOutOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ifEntry16
ifOutUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
ifOutUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
"The total number of packets that higher-level
protocols requested be transmitted, and which were not
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent."
::= { ifEntry 17 }
「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われなかったか、」 ::= ifEntry17
ifOutNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent.
ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われたか、」
This object is deprecated in favour of
ifOutMulticastPkts and ifOutBroadcastPkts."
::= { ifEntry 18 }
「このオブジェクトはifOutMulticastPktsとifOutBroadcastPktsを支持して推奨しないです。」 ::= ifEntry18
ifOutDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of outbound packets which were chosen to
be discarded even though no errors had been detected
to prevent their being transmitted. One possible
reason for discarding such a packet could be to free
up buffer space."
::= { ifEntry 19 }
ifOutDiscards OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「誤りが全くそれらがあるのを伝えられた状態で防ぐために検出されていませんでしたが、捨てられるために選ばれた外国行きのパケットの数。」 「そのようなパケットを捨てる1つの可能な理由はバッファ領域を開けることであることができました。」 ::= ifEntry19
McCloghrie & Kastenholz [Page 32] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[32ページ]RFC1573はグループ発展1994年1月に連結します。
ifOutErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of
outbound packets that could not be transmitted because
of errors. For character-oriented or fixed-length
interfaces, the number of outbound transmission units
that could not be transmitted because of errors."
::= { ifEntry 20 }
「パケット指向のインタフェース、誤りのために伝えることができなかった外国行きのパケットの数」のためのifOutErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「キャラクタ指向の、または、固定長さのインタフェース、誤りのために送ることができなかった外国行きのトランスミッションユニットの数。」 ::= ifEntry20
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }
「出力パケットの長さは列に並ばせ(パケットで)」ifOutQLen OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述。 ::= ifEntry21
ifSpecific OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"A reference to MIB definitions specific to the
particular media being used to realize the interface.
It is recommended that this value point to an instance
of a MIB object in the media-specific MIB, i.e., that
this object have the semantics associated with the
InstancePointer textual convention defined in RFC
1443. In fact, it is recommended that the media-
specific MIB specify what value ifSpecific should/can
take for values of ifType. If no MIB definitions
specific to the particular media are available, the
value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }
「Aはインタフェースがわかるのに使用される特定のメディアに特定のMIB定義に参照をつける」ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述。 この値がメディア特有のMIBにMIBオブジェクトのインスタンスを示して、すなわち、このオブジェクトにはRFC1443で定義されるInstancePointerの原文のコンベンションに関連している意味論があるのは、お勧めです。 事実上、メディアの特定のMIBが、/がifTypeの値に取ることができるなら何がifSpecificを評価するかを指定するのは、お勧めです。 「特定のメディアに特定のどんなMIB定義も利用可能でないなら、値はOBJECT IDENTIFIER0 0に設定されるべきです。」 ::= ifEntry22
-- -- Extension to the interface table -- -- This table replaces the ifExtnsTable table. --
-- -- インタフェーステーブルへの拡大----このテーブルはifExtnsTableテーブルを取り替えます。 --
ifXTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfXEntry
MAX-ACCESS not-accessible
アクセスしやすくないifXTable OBJECT-TYPE SYNTAX SEQUENCE OF IfXEntryマックス-ACCESS
McCloghrie & Kastenholz [Page 33] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[33ページ]RFC1573はグループ発展1994年1月に連結します。
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries
is given by the value of ifNumber. This table
contains additional objects for the interface table."
::= { ifMIBObjects 1 }
「Aはインタフェースエントリーについて記載する」STATUSの現在の記述。 ifNumberの値でエントリーの数を与えます。 「このテーブルはインタフェーステーブルのための追加オブジェクトを含んでいます。」 ::= ifMIBObjects1
ifXEntry OBJECT-TYPE
SYNTAX IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional management information
applicable to a particular interface."
AUGMENTS { ifEntry }
::= { ifXTable 1 }
ifXEntry OBJECT-TYPE SYNTAX IfXEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のインタフェースに適切な追加経営情報を含むエントリー。」 ifEntryを増大させます:、:= ifXTable1
IfXEntry ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
ifHCInBroadcastPkts Counter64,
ifHCOutOctets Counter64,
ifHCOutUcastPkts Counter64,
ifHCOutMulticastPkts Counter64,
ifHCOutBroadcastPkts Counter64,
ifLinkUpDownTrapEnable INTEGER,
ifHighSpeed Gauge32,
ifPromiscuousMode TruthValue,
ifConnectorPresent TruthValue
}
IfXEntry:、:= 系列ifName DisplayString、ifInMulticastPkts Counter32、ifInBroadcastPkts Counter32、ifOutMulticastPkts Counter32、ifOutBroadcastPkts Counter32、ifHCInOctets Counter64、ifHCInUcastPkts Counter64、ifHCInMulticastPkts Counter64、ifHCInBroadcastPkts Counter64、ifHCOutOctets Counter64、ifHCOutUcastPkts Counter64、ifHCOutMulticastPkts Counter64、ifHCOutBroadcastPkts Counter64、ifLinkUpDownTrapEnable整数、ifHighSpeed Gauge32、ifPromiscuousMode TruthValue、ifConnectorPresent TruthValue
ifName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The textual name of the interface. The value of this
object should be the name of the interface as assigned
by the local device and should be suitable for use in
commands entered at the device's `console'. This
「原文はインタフェースについて命名する」ifName OBJECT-TYPE SYNTAX DisplayStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このオブジェクトの値は、ローカル装置によって割り当てられるようにインタフェースの名前であるべきであり、デバイスの'コンソール'に入力されたコマンドにおける使用に適しているべきです。 これ
McCloghrie & Kastenholz [Page 34] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[34ページ]RFC1573はグループ発展1994年1月に連結します。
might be a text name, such as `le0' or a simple port
number, such as `1', depending on the interface naming
syntax of the device. If several entries in the
ifTable together represent a single interface as named
by the device, then each will have the same value of
ifName. If there is no local name, or this object is
otherwise not applicable, then this object contains a
0-length string."
::= { ifXEntry 1 }
デバイスのインタフェース命名構文による'le0'か簡単なポートナンバーなどの'1などの'原文名はそうですか? 一緒にifTableのいくつかのエントリーがデバイスによって命名されるように単一のインタフェースを表すと、それぞれには、ifNameの同じ値があるでしょう。 「地方名が全くないか、またはそうでなければ、このオブジェクトが適切でないなら、このオブジェクトは0長さのストリングを含んでいます。」 ::= ifXEntry1
ifInMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
multicast address at this sub-layer. For a MAC layer
protocol, this includes both Group and Functional
addresses."
::= { ifXEntry 2 }
ifInMulticastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストアドレスに扱われました)。 「MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。」 ::= ifXEntry2
ifInBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
broadcast address at this sub-layer."
::= { ifXEntry 3 }
ifInBroadcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層の放送演説に扱われました)。 ::= ifXEntry3
ifOutMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast address at this sub-layer,
including those that were discarded or not sent. For
a MAC layer protocol, this includes both Group and
Functional addresses."
::= { ifXEntry 4 }
ifOutMulticastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層のaマルチキャストアドレスに扱われたか、」 「MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。」 ::= ifXEntry4
ifOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
ifOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32マックス-ACCESS書き込み禁止
McCloghrie & Kastenholz [Page 35] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[35ページ]RFC1573はグループ発展1994年1月に連結します。
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a broadcast address at this sub-layer,
including those that were discarded or not sent."
::= { ifXEntry 5 }
STATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層の放送のアドレスに扱われたか、」 ::= ifXEntry5
-- -- High Capacity Counter objects. These objects are all
-- -- 高いCapacity Counterは反対します。 これらのオブジェクトはすべてです。
-- 64 bit versions of the "basic" ifTable counters. These -- objects all have the same basic semantics as their 32-bit -- counterparts, however, their syntax has been extended -- to 64 bits. --
-- 64は「基本的な」ifTableカウンタのバージョンに噛み付きました。 これら--オブジェクトにはすべて、対応者、しかしながら、彼らの構文を広げてあるというそれらの32ビットと同じ基本的な意味論が64ビットまであります。 --
ifHCInOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
including framing characters. This object is a 64-bit
version of ifInOctets."
::= { ifXEntry 6 }
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースで受けた」ifHCInOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「このオブジェクトはifInOctetsの64ビットのバージョンです。」 ::= ifXEntry6
ifHCInUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were not addressed to a
multicast or broadcast address at this sub-layer.
This object is a 64-bit version of ifInUcastPkts."
::= { ifXEntry 7 }
ifHCInUcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストか放送演説に扱われませんでした)。 「このオブジェクトはifInUcastPktsの64ビットのバージョンです。」 ::= ifXEntry7
ifHCInMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
multicast address at this sub-layer. For a MAC layer
protocol, this includes both Group and Functional
addresses. This object is a 64-bit version of
ifHCInMulticastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストアドレスに扱われました)。 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。 このオブジェクトは64ビットのバージョンです。
McCloghrie & Kastenholz [Page 36] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[36ページ]RFC1573はグループ発展1994年1月に連結します。
ifInMulticastPkts."
::= { ifXEntry 8 }
「ifInMulticastPkts。」 ::= ifXEntry8
ifHCInBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to
a higher (sub-)layer, which were addressed to a
broadcast address at this sub-layer. This object is a
64-bit version of ifInBroadcastPkts."
::= { ifXEntry 9 }
ifHCInBroadcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層の放送演説に扱われました)。 「このオブジェクトはifInBroadcastPktsの64ビットのバージョンです。」 ::= ifXEntry9
ifHCOutOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters. This object
is a 64-bit version of ifOutOctets."
::= { ifXEntry 10 }
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースから伝えた」ifHCOutOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「このオブジェクトはifOutOctetsの64ビットのバージョンです。」 ::= ifXEntry10
ifHCOutUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were not
addressed to a multicast or broadcast address at this
sub-layer, including those that were discarded or not
sent. This object is a 64-bit version of
ifOutUcastPkts."
::= { ifXEntry 11 }
ifHCOutUcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われなかったか、」 「このオブジェクトはifOutUcastPktsの64ビットのバージョンです。」 ::= ifXEntry11
ifHCOutMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a multicast address at this sub-layer,
including those that were discarded or not sent. For
a MAC layer protocol, this includes both Group and
Functional addresses. This object is a 64-bit version
ifHCOutMulticastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層のaマルチキャストアドレスに扱われたか、」 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。 このオブジェクトは64ビットのバージョンです。
McCloghrie & Kastenholz [Page 37] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[37ページ]RFC1573はグループ発展1994年1月に連結します。
of ifOutMulticastPkts."
::= { ifXEntry 12 }
「ifOutMulticastPkts。」 ::= ifXEntry12
ifHCOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level
protocols requested be transmitted, and which were
addressed to a broadcast address at this sub-layer,
including those that were discarded or not sent. This
object is a 64-bit version of ifOutBroadcastPkts."
::= { ifXEntry 13 }
ifHCOutBroadcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層の放送のアドレスに扱われたか、」 「このオブジェクトはifOutBroadcastPktsの64ビットのバージョンです。」 ::= ifXEntry13
ifLinkUpDownTrapEnable OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether linkUp/linkDown traps should be
generated for this interface.
(1)を可能にして、(2)であることが無効にされたマックス-ACCESSが「linkUp/linkDown罠がこのインタフェースに生成されるべきであるかどうかを示す」とSTATUSの現在の記述に読書して書くifLinkUpDownTrapEnable OBJECT-TYPE SYNTAX INTEGER。
By default, this object should have the value
enabled(1) for interfaces which do not operate on
'top' of any other interface (as defined in the
ifStackTable), and disabled(2) otherwise."
::= { ifXEntry 14 }
「(1) (2) そうでなければ、するインタフェースがいかなる他のインタフェースの'先端'(ifStackTableで定義されるように)、および身体障害者も手術しないので、デフォルトで、このオブジェクトは値を可能にするはずです。」 ::= ifXEntry14
ifHighSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in
units of 1,000,000 bits per second. If this object
reports a value of `n' then the speed of the interface
is somewhere in the range of `n-500,000' to
`n+499,999'. For interfaces which do not vary in
bandwidth or for those where no accurate estimation
can be made, this object should contain the nominal
bandwidth. For a sub-layer which has no concept of
bandwidth, this object should be zero."
::= { ifXEntry 15 }
ifHighSpeed OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「100万のbpsのユニットにおけるインタフェースの現在の帯域幅の見積り。」 'このオブジェクトが値を報告する、'インタフェースの速度が範囲のどこかにあるその時、-50万、'、+499,999' 帯域幅で異ならないインタフェースかどんな正確な見積りもすることができないところのそれらに関しては、このオブジェクトは呼び帯域幅を含むはずです。 「帯域幅の概念を全く持っていない副層のために、このオブジェクトはゼロであるべきです。」 ::= ifXEntry15
ifPromiscuousMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
ifPromiscuousMode OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは読書して書きます。
McCloghrie & Kastenholz [Page 38] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[38ページ]RFC1573はグループ発展1994年1月に連結します。
STATUS current
DESCRIPTION
"This object has a value of false(2) if this interface
only accepts packets/frames that are addressed to this
station. This object has a value of true(1) when the
station accepts all packets/frames transmitted on the
media. The value true(1) is only legal on certain
types of media. If legal, setting this object to a
value of true(1) may require the interface to be reset
before becoming effective.
「このオブジェクトには(2) このインタフェースがこのステーションに扱われるパケット/フレームを受け入れるだけであるなら、値が虚偽である」STATUSの現在の記述。 ステーションがメディアで伝えられたすべてのパケット/フレームを受け入れるとき、このオブジェクトには、本当の(1)の値があります。 値の本当の(1)は単にあるタイプのメディアで法的です。 法的であるなら、本当の(1)の値にこのオブジェクトを設定するのは、インタフェースが有効になる前にリセットされるのを必要とするかもしれません。
The value of ifPromiscuousMode does not affect the
reception of broadcast and multicast packets/frames by
the interface."
::= { ifXEntry 16 }
「ifPromiscuousModeの値はインタフェースのそばで放送とマルチキャストパケット/フレームのレセプションに影響しません。」 ::= ifXEntry16
ifConnectorPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object has the value 'true(1)' if the interface
sublayer has a physical connector and the value
'false(2)' otherwise."
::= { ifXEntry 17 }
(1) '(2) 'そうでなければ、インタフェース副層には、物理的なコネクタと値が'虚偽である」なら、ifConnectorPresent OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は本当に「値を持これが反対するしています'。 ::= ifXEntry17
-- The Interface Stack Group -- -- Implementation of this group is mandatory for all systems --
-- Interface Stack Group----このグループの実装はすべてのシステムに義務的です--
ifStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table containing information on the relationships
between the multiple sub-layers of network interfaces.
In particular, it contains information on which sub-
layers run 'on top of' which other sub-layers. Each
sub-layer corresponds to a conceptual row in the
ifTable."
::= { ifMIBObjects 2 }
「ネットワークの複数の副層の間の関係のテーブルの含んでいる情報は連結する」ifStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfStackEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 特に、それはサブ層がどの他の副層'上'で動く情報を含んでいます。 「各副層はifTableの概念的な行に対応しています。」 ::= ifMIBObjects2
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
ifStackEntryオブジェクト・タイプ構文IfStackEntry
McCloghrie & Kastenholz [Page 39] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[39ページ]RFC1573はグループ発展1994年1月に連結します。
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer runs on
'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
マックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「2つの副層の間の特定の関係に関する情報、1つの副層が走る指定'は'もう片方の副層」を付けます。 「各副層はifTableの概念的な行に対応しています。」 ifStackHigherLayer、ifStackLowerLayerに索引をつけてください:、:= ifStackTable1
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer Integer32,
ifStackLowerLayer Integer32,
ifStackStatus RowStatus
}
IfStackEntry:、:= 系列ifStackHigherLayer Integer32、ifStackLowerLayer Integer32、ifStackStatus RowStatus
ifStackHigherLayer OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher
sub-layer of the relationship, i.e., the sub-layer
which runs on 'top' of the sub-layer identified by the
corresponding instance of ifStackLowerLayer. If there
is no higher sub-layer (below the internetwork layer),
then this object has the value 0."
::= { ifStackEntry 1 }
「すなわち、関係の、より高い副層、'先端'で走る副層の副層に対応するifIndexの値はifStackLowerLayerの対応するインスタンスで特定した」ifStackHigherLayer OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「どんなより高い副層(インターネットワーク層の下における)もなければ、このオブジェクトには、値0があります。」 ::= ifStackEntry1
ifStackLowerLayer OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-
layer of the relationship, i.e., the sub-layer which
runs 'below' the sub-layer identified by the
corresponding instance of ifStackHigherLayer. If
there is no lower sub-layer, then this object has the
value 0."
::= { ifStackEntry 2 }
ifStackLowerLayer OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「すなわち、関係の低級サブ層、副層がifStackHigherLayerの対応するインスタンスで特定した'below'を実行する副層に対応するifIndexの値。」 「どんな低級副層もなければ、このオブジェクトには、値0があります。」 ::= ifStackEntry2
ifStackStatus OBJECT-TYPE
ifStackStatusオブジェクト・タイプ
McCloghrie & Kastenholz [Page 40] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[40ページ]RFC1573はグループ発展1994年1月に連結します。
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The status of the relationship between two sub-
layers.
SYNTAX RowStatusマックス-ACCESSは「2つのサブ層の間の関係の状態」をSTATUSの現在の記述に読書して書きます。
Changing the value of this object from 'active' to
'notInService' or 'destroy' will likely have
consequences up and down the interface stack. Thus,
write access to this object is likely to be
inappropriate for some types of interfaces, and many
implementations will choose not to support write-
access for any type of interface."
::= { ifStackEntry 3 }
このオブジェクトの値を'アクティブ'から'notInService'か'破壊'に変えると、結果はおそらく上下にインタフェーススタックに持たれるでしょう。 「その結果、インタフェースのいくつかにはおそらく不適当であることになっているこれが、反対する実装がサポートしないのを選ぶインタフェース、および多くのタイプがタイプするといずれのためのアクセスを書くアクセスを書いてください。」 ::= ifStackEntry3
-- -- The Interface Test Table -- -- This group of objects is optional. However, a media-specific -- MIB may make implementation of this group mandatory. -- -- This table replaces the ifExtnsTestTable --
-- -- Interface Test Table----オブジェクトのこのグループは任意です。 しかしながら、メディア詳細--MIBはこのグループの実装を義務的にするかもしれません。 -- -- このテーブルはifExtnsTestTableを取り替えます--
ifTestTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfTestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one entry per interface. It
defines objects which allow a network manager to
instruct an agent to test an interface for various
faults. Tests for an interface are defined in the
media-specific MIB for that interface. After invoking
a test, the object ifTestResult can be read to
determine the outcome. If an agent can not perform
the test, ifTestResult is set to so indicate. The
object ifTestCode can be used to provide further
test-specific or interface-specific (or even
enterprise-specific) information concerning the
outcome of the test. Only one test can be in progress
on each interface at any one time. If one test is in
progress when another test is invoked, the second test
is rejected. Some agents may reject a test when a
prior test is active on another interface.
「このテーブルは1インタフェースあたり1つのエントリーに含む」ifTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfTestEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 それはネットワークマネージャが様々な欠点がないかどうかインタフェースをテストするようエージェントに命令できるオブジェクトを定義します。 インタフェースのためのテストはメディア特有のMIBでそのインタフェースと定義されます。 テストを呼び出した後に、結果を決定するためにオブジェクトifTestResultを読むことができます。 エージェントが働くことができないなら、テスト、ifTestResultは用意ができています。そのように、示します。 テストの結果に関して試しにさらに特有の、または、インタフェース特有の、そして、(企業特有さえ)の情報を提供するのにオブジェクトifTestCodeを使用できます。 1つのテストしかいかなる時も、各インタフェースで進行できません。 別のテストが呼び出されるとき、1つのテストが進行しているなら、2番目のテストは拒絶されます。 先のテストが別のインタフェースで活発であるときにテストを拒絶するエージェントもいるかもしれません。
McCloghrie & Kastenholz [Page 41] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[41ページ]RFC1573はグループ発展1994年1月に連結します。
Before starting a test, a manager-station must first
obtain 'ownership' of the entry in the ifTestTable for
the interface to be tested. This is accomplished with
the ifTestId and ifTestStatus objects as follows:
テストを始める前に、マネージャステーションは、最初に、インタフェースがテストされるためにifTestTableでエントリーの'所有権'を得なければなりません。 ifTestIdとifTestStatusオブジェクトは以下の通りでこれは達成されます:
try_again:
get (ifTestId, ifTestStatus)
while (ifTestStatus != notInUse)
/*
* Loop while a test is running or some other
* manager is configuring a test.
*/
short delay
get (ifTestId, ifTestStatus)
}
_もう一度試みてください: (ifTestStatus!はnotInUseと等しいです)/**輪がテストが稼働かある他の*マネージャである間、テストを構成している間、得てください(ifTestId、ifTestStatus)。 */ショート遅れは(ifTestId、ifTestStatus)を得ます。
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
/**はたった今、使用されていません--競争しましょう。*だれかに会うのはそれを得ます。 */錠_値はifTestIdと等しいです。
if ( set(ifTestId = lock_value, ifTestStatus = inUse,
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
**(=FAILUREを設定します(ifTestId=錠_価値、ifTestStatus=inUse、ifTestOwnerは'私のIPアドレス'と等しいです))/であるなら、別のマネージャはifTestEntryを手に入れました--碁*は再び再び*/gotoトライ_を試みます。
/*
* I have the lock
*/
set up any test parameters.
私が錠*/にどんなテストパラメタにも設定させる/**。
/*
* This starts the test
*/
set(ifTestType = test_to_run);
/、**これはテスト*/セットを始動します(ifTestTypeは_走行へのテスト_と等しいです)。
wait for test completion by polling ifTestResult
世論調査ifTestResultによるテスト完成を待ってください。
when test completes, agent sets ifTestResult
agent also sets ifTestStatus = 'notInUse'
テストが完成するいつ、エージェントセットifTestResultエージェントセットもifTestStatus='notInUse'
retrieve any additional test results, and ifTestId
あらゆる追加試験の成績、およびifTestIdを検索してください。
if (ifTestId == lock_value+1) results are valid
(ifTestId=錠_価値+1)結果が有効であるなら
McCloghrie & Kastenholz [Page 42] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[42ページ]RFC1573はグループ発展1994年1月に連結します。
A manager station first retrieves the value of the
appropriate ifTestId and ifTestStatus objects,
periodically repeating the retrieval if necessary,
until the value of ifTestStatus is 'notInUse'. The
manager station then tries to set the same ifTestId
object to the value it just retrieved, the same
ifTestStatus object to 'inUse', and the corresponding
ifTestOwner object to a value indicating itself. If
the set operation succeeds then the manager has
obtained ownership of the ifTestEntry, and the value of
the ifTestId object is incremented by the agent (per
the semantics of TestAndIncr). Failure of the set
operation indicates that some other manager has
obtained ownership of the ifTestEntry.
マネージャステーションは最初に適切なifTestIdとifTestStatusオブジェクトの値を検索します、必要なら、定期的に検索を繰り返して、ifTestStatusの値が'notInUse'になるまで。 そして、マネージャステーションはそれがただ検索した値、'inUse'への同じifTestStatusオブジェクト、およびそれ自体を示す値への対応するifTestOwnerオブジェクトに同じifTestIdオブジェクトを設定しようとします。 集合演算が成功するなら、マネージャはifTestEntryの所有権を得ました、そして、ifTestIdオブジェクトの値はエージェント(TestAndIncrの意味論あたりの)によって増加されます。 集合演算の失敗は、ある他のマネージャがifTestEntryの所有権を得たのを示します。
Once ownership is obtained, any test parameters can be
setup, and then the test is initiated by setting
ifTestType. On completion of the test, the agent sets
ifTestStatus to 'notInUse'. Once this occurs, the
manager can retrieve the results. In the (rare) event
that the invocation of tests by two network managers
were to overlap, then there would be a possibility that
the first test's results might be overwritten by the
second test's results prior to the first results being
read. This unlikely circumstance can be detected by a
network manager retrieving ifTestId at the same time as
retrieving the test results, and ensuring that the
results are for the desired request.
いったん所有権を得ると、どんなテストパラメタもセットアップであるかもしれません、そして、次に、テストは、ifTestTypeを設定することによって、開始されます。 テストの完成のときに、エージェントは'notInUse'にifTestStatusを設定します。 これがいったん起こると、マネージャは結果を検索できます。 そして、2つのネットワークマネージャによるテストの実施が重ね合わせることになっていた(まれ)のイベントには、一次テストの結果が読まれる最初の結果の前に2番目のテストの結果によって上書きされるかもしれない可能性があるでしょう。 試験の成績を検索することと同時にifTestIdを検索して、結果が必要な要求のためのものであることを確実にするネットワークマネージャはこのありそうもない状況を検出できます。
If ifTestType is not set within an abnormally long
period of time after ownership is obtained, the agent
should time-out the manager, and reset the value of the
ifTestStatus object back to 'notInUse'. It is
suggested that this time-out period be 5 minutes.
所有権を得た後にifTestTypeが時間の異常に長い期間以内に用意ができていないなら、エージェントが用意ができるべきである、タイムアウト、マネージャ、およびifTestStatusオブジェクトの値が'notInUse'に支持するリセット。 このタイムアウトの期間が5分であると示唆されます。
In general, a management station must not retransmit a
request to invoke a test for which it does not receive
a response; instead, it properly inspects an agent's
MIB to determine if the invocation was successful.
Only if the invocation was unsuccessful, is the
invocation request retransmitted.
一般に、管理局はそれが応答を受けないテストを呼び出すという要求を再送してはいけません。 代わりに、それは、実施がうまくいったかどうか決定するために適切にエージェントのMIBを点検します。 実施が失敗していた場合にだけ、実施の要求は再送されますか?
Some tests may require the interface to be taken off-
line in order to execute them, or may even require the
agent to reboot after completion of the test. In these
circumstances, communication with the management
station invoking the test may be lost until after
completion of the test. An agent is not required to
いくつかのテストが、それらを実行するのにインタフェースが系列で取られるのが必要である、またはエージェントがテストの完成の後にリブートするのを必要とさえするかもしれません。 こういう事情ですから、テストを呼び出す管理局とのコミュニケーションはテストの完成の後まで失われるかもしれません。 エージェントは必要ではありません。
McCloghrie & Kastenholz [Page 43] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[43ページ]RFC1573はグループ発展1994年1月に連結します。
support such tests. However, if such tests are
supported, then the agent should make every effort to
transmit a response to the request which invoked the
test prior to losing communication. When the agent is
restored to normal service, the results of the test are
properly made available in the appropriate objects.
Note that this requires that the ifIndex value assigned
to an interface must be unchanged even if the test
causes a reboot. An agent must reject any test for
which it cannot, perhaps due to resource constraints,
make available at least the minimum amount of
information after that test completes."
::= { ifMIBObjects 3 }
そのようなテストをサポートしてください。 しかしながら、そのようなテストがサポートされるなら、エージェントは、損をしているコミュニケーションの前にテストを呼び出した要求への応答を伝えるためにあらゆる努力するべきです。 エージェントが通常のサービスに回復するとき、適切なオブジェクトで適切にテストの結果を利用可能にします。 これが、テストがリブートを引き起こしてもインタフェースに割り当てられたifIndex値が変わりがないに違いないのを必要とすることに注意してください。 「エージェントはそれが恐らくリソース規制のためテストが完成するその後の情報の有効な最小の量を作ることができないどんなテストも拒絶しなければなりません。」 ::= ifMIBObjects3
ifTestEntry OBJECT-TYPE
SYNTAX IfTestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing objects for invoking tests on an
interface."
AUGMENTS { ifEntry }
::= { ifTestTable 1 }
「エントリー含有はインタフェースのテストを呼び出すために反対させる」ifTestEntry OBJECT-TYPE SYNTAX IfTestEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ifEntryを増大させます:、:= ifTestTable1
IfTestEntry ::=
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
ifTestOwner OwnerString
}
IfTestEntry:、:= 系列ifTestId TestAndIncr、ifTestStatus整数、ifTestType AutonomousType、ifTestResult整数、ifTestCodeオブジェクト識別子、ifTestOwner OwnerString
ifTestId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the current invocation of the
interface's test."
::= { ifTestEntry 1 }
ifTestId OBJECT-TYPE SYNTAX TestAndIncrマックス-ACCESSは「このオブジェクトはインタフェースのテストの現在の実施を特定すること」をSTATUSの現在の記述に読書して書きます。 ::= ifTestEntry1
ifTestStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
ifTestStatus OBJECT-TYPE SYNTAX INTEGER、notInUse(1)、マックス-ACCESSがSTATUS現在の記述を読書して書くinUse(2)
McCloghrie & Kastenholz [Page 44] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[44ページ]RFC1573はグループ発展1994年1月に連結します。
"This object indicates whether or not some manager
currently has the necessary 'ownership' required to
invoke a test on this interface. A write to this
object is only successful when it changes its value
from 'notInUse(1)' to 'inUse(2)'. After completion of
a test, the agent resets the value back to
'notInUse(1)'."
::= { ifTestEntry 2 }
「このオブジェクトは、マネージャが現在このインタフェースのテストを呼び出すために必要な'所有権'を必要とさせるかどうかを示します。」 Aが単に書く、値を'notInUse(1)'から'inUse(2)'に変えるとき、このオブジェクトはうまくいっています。 「テストの完成の後に、エージェントは'notInUse(1)'に値をリセットして戻します。」 ::= ifTestEntry2
ifTestType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control variable used to start and stop operator-
initiated interface tests. Most OBJECT IDENTIFIER
values assigned to tests are defined elsewhere, in
association with specific types of interface.
However, this document assigns a value for a full-
duplex loopback test, and defines the special meanings
of the subject identifier:
ifTestType OBJECT-TYPE SYNTAX AutonomousTypeマックス-ACCESSは「制御変数が以前はよく始まっていました、そして、停止オペレータはインタフェーステストを開始したこと」をSTATUSの現在の記述に読書して書きます。 テストに割り当てられたほとんどのOBJECT IDENTIFIER値がほかの場所で特定のタイプのインタフェースと関連して定義されます。 しかしながら、このドキュメントは、完全な重複の折返しテストのために値を割り当てて、対象の識別子の特別な意味を定義します:
noTest OBJECT IDENTIFIER ::= { 0 0 }
最もnoTestなオブジェクト識別子:、:= { 0 0 }
When the value noTest is written to this object, no
action is taken unless a test is in progress, in which
case the test is aborted. Writing any other value to
this object is only valid when no test is currently in
progress, in which case the indicated test is
initiated.
このオブジェクトに値のnoTestを書いて、テストが進行していない場合、行動を全く取りません、その場合、テストを中止します。 テストが全く現在進行していないときだけ、このオブジェクトにいかなる他の値も書くのが有効である、その場合、示されたテストは開始されます。
When read, this object always returns the most recent
value that ifTestType was set to. If it has not been
set since the last initialization of the network
management subsystem on the agent, a value of noTest
is returned."
::= { ifTestEntry 3 }
読まれると、このオブジェクトはいつもifTestTypeが用意ができていた最新の値を返します。 「エージェントにおけるネットワークマネージメントサブシステムの最後の初期化以来それを設定していないなら、noTestの値を返します。」 ::= ifTestEntry3
ifTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
ifTestResultオブジェクト・タイプ構文整数システムの事情への(1)(テストがないのにもかかわらず、要求された成功(2)、inProgress(3)、notSupported(4)、unAbleToRun(5))当然のなにも、(6)を中止して、(7)を失敗しませんでした。
McCloghrie & Kastenholz [Page 45] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[45ページ]RFC1573はグループ発展1994年1月に連結します。
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the result of the most recently
requested test, or the value none(1) if no tests have
been requested since the last reset. Note that this
facility provides no provision for saving the results
of one test when starting another, as could be
required if used by multiple managers concurrently."
::= { ifTestEntry 4 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「(1) どんなテストも含んでいないならこのオブジェクトがなにもに最も最近要求されたテストの結果、または値を含んでいる、最後のリセット以来要求されている、」 「この施設が同時に複数のマネージャによって使用されるなら必要であるかもしれないように別のものを始めるときの1つのテストの結果を節約することへの支給を全く提供しないことに注意してください。」 ::= ifTestEntry4
ifTestCode OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains a code which contains more
specific information on the test result, for example
an error-code after a failed test. Error codes and
other values this object may take are specific to the
type of interface and/or test. The value may have the
semantics of either the AutonomousType or
InstancePointer textual conventions as defined in RFC
1443. The identifier:
ifTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「失敗したテストの後にテスト結果の、より特定の情報を含むコード、例えばエラーコードを含これが反対するしています」。 インタフェース、そして/または、テストのタイプに、このオブジェクトが取るかもしれないエラーコードと他の値は特定です。 値には、AutonomousTypeかInstancePointerの原文のコンベンションの意味論がRFC1443で定義されるようにあるかもしれません。 識別子:
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
testCodeUnknownオブジェクト識別子:、:= { 0 0 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }
「使用のために、どんな追加結果コードも利用可能でないなら、定義されます。」 ::= ifTestEntry5
ifTestOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The entity which currently has the 'ownership'
required to invoke a test on this interface."
::= { ifTestEntry 6 }
ifTestOwner OBJECT-TYPE SYNTAX OwnerStringマックス-ACCESSは「現在このインタフェースのテストを呼び出すために'所有権'を必要とする実体」をSTATUSの現在の記述に読書して書きます。 ::= ifTestEntry6
-- Generic Receive Address Table -- -- This group of objects is mandatory for all types of -- interfaces which can receive packets/frames addressed to -- more than one address. -- -- This table replaces the ifExtnsRcvAddr table. The main
-- ジェネリックReceive Address Table----オブジェクトのこのグループは--缶が扱われたパケット/フレームを受けるインタフェースより--1つ以上のアドレスのすべてのタイプに義務的です。 -- -- このテーブルはifExtnsRcvAddrテーブルを取り替えます。 メイン
McCloghrie & Kastenholz [Page 46] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[46ページ]RFC1573はグループ発展1994年1月に連結します。
-- difference is that this table makes use of the RowStatus -- textual convention, while ifExtnsRcvAddr did not.
-- 違いはこのテーブルがRowStatusを利用するということです--ifExtnsRcvAddrがそうしなかった間の原文のコンベンション。
ifRcvAddressTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains an entry for each address
(broadcast, multicast, or uni-cast) for which the
system will receive packets/frames on a particular
interface, except as follows:
ifRcvAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IfRcvAddressEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルはシステムが特定のインタフェースでパケット/フレームを受ける各アドレス(放送、マルチキャスト、またはユニキャスト)のためのエントリーを含んでいます、以下の通りを除いて」
- for an interface operating in promiscuous mode,
entries are only required for those addresses for
which the system would receive frames were it not
operating in promiscuous mode.
- 無差別なモードで作動するインタフェースに関しては、エントリーが無差別なモードで作動していないならシステムがフレーム搬入するそれらのアドレスに必要であるだけです。
- for 802.5 functional addresses, only one entry is
required, for the address which has the functional
address bit ANDed with the bit mask of all functional
addresses for which the interface will accept frames."
::= { ifMIBObjects 4 }
- 「802.5の機能アドレスに、1つのエントリーだけが必要です、インタフェースがフレームを受け入れるすべての機能アドレスの噛み付いているマスクがある機能アドレスビットANDedを持っているアドレスのために。」 ::= ifMIBObjects4
ifRcvAddressEntry OBJECT-TYPE
SYNTAX IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of objects identifying an address for which
the system will accept packets/frames on the
particular interface identified by the index value
ifIndex."
INDEX { ifIndex, ifRcvAddressAddress }
::= { ifRcvAddressTable 1 }
「オブジェクトがシステムが特定のインタフェースでパケット/フレームを受け入れるアドレスを特定するリストはインデックス価値のifIndexで特定した」ifRcvAddressEntry OBJECT-TYPE SYNTAX IfRcvAddressEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ifIndex、ifRcvAddressAddressに索引をつけてください:、:= ifRcvAddressTable1
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
IfRcvAddressEntry:、:= 系列ifRcvAddressAddress PhysAddress、ifRcvAddressStatus RowStatus、ifRcvAddressType整数
ifRcvAddressAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
ifRcvAddressAddress OBJECT-TYPE SYNTAX PhysAddressマックス-ACCESSはSTATUSの現在の記述を読書して作成します。
McCloghrie & Kastenholz [Page 47] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[47ページ]RFC1573はグループ発展1994年1月に連結します。
"An address for which the system will accept
packets/frames on this entry's interface."
::= { ifRcvAddressEntry 1 }
「システムがこのエントリーのインタフェースでパケット/フレームを受け入れるアドレス。」 ::= ifRcvAddressEntry1
ifRcvAddressStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to create and delete rows in the
ifRcvAddressTable."
ifRcvAddressStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「このオブジェクトはifRcvAddressTableの行を作成して、削除するのに使用されること」をSTATUSの現在の記述に読書して書きます。
::= { ifRcvAddressEntry 2 }
::= ifRcvAddressEntry2
ifRcvAddressType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
volatile(2),
nonVolatile(3)
}
ifRcvAddressTypeオブジェクト・タイプ構文整数他の(1)、揮発性の(2)、nonVolatile(3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object has the value nonVolatile(3) for those
entries in the table which are valid and will not be
deleted by the next restart of the managed system.
Entries having the value volatile(2) are valid and
exist, but have not been saved, so that will not exist
after the next restart of the managed system. Entries
having the value other(1) are valid and exist but are
not classified as to whether they will continue to
exist after the next restart."
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトは、有効なテーブルにそれらのエントリーへの値のnonVolatile(3)を持って、管理されたシステムの次の再開で削除されないでしょう」。 値の揮発性の(2)を持っているエントリーが、有効であり、存在しますが、それが管理されたシステムの次の再開の後に存在しないように、貯蓄されないでください。 「値の他の(1)を持っているエントリーが、有効であり、存在していますが、それらが次の再開の後に存続するかどうかに関して分類されません。」
DEFVAL { volatile }
DEFVAL揮発性
::= { ifRcvAddressEntry 3 }
::= ifRcvAddressEntry3
-- definition of interface-related traps.
-- インタフェース関連の罠の定義。
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication links
linkDown NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「linkDown罠が、エージェントの役割で行動して、SNMPv2実体がそれを検出したのを意味する、ifOperStatusが通信リンクの1つのために反対する、」
McCloghrie & Kastenholz [Page 48] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[48ページ]RFC1573はグループ発展1994年1月に連結します。
is about to transition into the down state."
::= { snmpTraps 3 }
「下に状態に移行しようとしていることになっています。」 ::= snmpTraps3
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication links
has transitioned out of the down state."
::= { snmpTraps 4 }
linkUp NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「linkUp罠が、エージェントの役割で行動して、SNMPv2実体がそれを検出したのを意味する、通信リンクの1つのifOperStatusオブジェクトが下に状態から移行した、」 ::= snmpTraps4
-- conformance information
-- 順応情報
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifConformanceオブジェクト識別子:、:= ifMIB2
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
ifGroupsオブジェクト識別子:、:= ifConformance1ifCompliancesオブジェクト識別子:、:= ifConformance2
-- compliance statements
-- 承諾声明
ifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
have network interfaces."
ifCompliance MODULE-COMPLIANCE STATUSの現在の記述、「ネットワークを持っているSNMPv2実体のための承諾声明は連結します」。
MODULE -- this module
MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
MODULE--このモジュールMANDATORY-GROUPSifGeneralGroup、ifStackGroup
GROUP ifFixedLengthGroup
DESCRIPTION
"This group is mandatory for all network interfaces
which are character-oriented or transmit data in
fixed-length transmission units."
GROUP ifFixedLengthGroup記述、「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送るすべてのネットワーク・インターフェースに義務的です」。
GROUP ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces which are character-oriented or transmit
data in fixed-length transmission units, and for which
the value of the corresponding instance of ifSpeed is
greater than 20,000,000 bits/second."
GROUP ifHCFixedLengthGroup記述、「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送って、ifSpeedの対応するインスタンスの値が2000万ビット/秒以上であるそれらのネットワーク・インターフェースだけに義務的です」。
GROUP ifPacketGroup
グループifPacketGroup
McCloghrie & Kastenholz [Page 49] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[49ページ]RFC1573はグループ発展1994年1月に連結します。
DESCRIPTION
"This group is mandatory for all network interfaces
which are packet-oriented."
記述、「このグループはすべてのパケット指向であることのネットワーク・インターフェースに義務的です」。
GROUP ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces which are packet-oriented and for which the
value of the corresponding instance of ifSpeed is
greater than 650,000,000 bits/second."
GROUP ifTestGroup
DESCRIPTION
"This group is optional. Media-specific MIBs which
require interface tests are strongly encouraged to use
this group for invoking tests and reporting results.
A medium specific MIB which has mandatory tests may
make implementation of this group mandatory."
GROUP ifHCPacketGroup記述、「このグループはパケット指向であり、ifSpeedの対応するインスタンスの値が6億5000万ビット/秒以上であるそれらのネットワーク・インターフェースだけに義務的です」。 GROUP ifTestGroup記述、「このグループは任意です」。 インタフェーステストを必要とするメディア特有のMIBsがテストを呼び出して、結果を報告するのにこのグループを使用するよう強く奨励されます。 「義務的なテストを持っている中型の特定のMIBはこのグループの実装を義務的にするかもしれません。」
GROUP ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by
the media-specific MIBs. Media-specific MIBs must
define the exact meaning, use, and semantics of the
addresses in this group."
GROUP ifRcvAddressGroup記述、「メディア特有のMIBsはこのグループの適用性を定義しなければなりません」。 「メディア特有のMIBsはこのグループでアドレスの正確な意味、使用、および意味論を定義しなければなりません。」
OBJECT ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifPromiscuousMode MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifStackStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
書いてください。OBJECT ifStackStatus SYNTAX INTEGERのアクティブな(1)--、RowStatus MIN-ACCESS書き込み禁止記述の部分集合、「アクセスは必要ではありません、そして、RowStatusの原文のコンベンションのための6つの列挙された値の1つだけが明確にサポートされなければなりません:、」 「アクティブな(1)。」
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the
(2)への(1)へのOBJECT ifAdminStatus SYNTAX INTEGER、MIN-ACCESS書き込み禁止記述、「書く、アクセスが必要でなく、サポートである、」
McCloghrie & Kastenholz [Page 50] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[50ページ]RFC1573はグループ発展1994年1月に連結します。
value testing(3)."
::= { ifCompliances 1 }
「テスト(3)を評価してください。」 ::= ifCompliances1
-- units of conformance
-- ユニットの順応
ifGeneralGroup OBJECT-GROUP
OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName }
STATUS current
DESCRIPTION
"A collection of objects providing information
applicable to all network interfaces."
::= { ifGroups 1 }
ifGeneralGroup OBJECT-GROUP OBJECTS、ifDescr、ifType、ifSpeed、ifPhysAddress、ifAdminStatus、ifOperStatus、ifLastChange、ifLinkUpDownTrapEnable、ifConnectorPresent、ifHighSpeed、ifName、「オブジェクトがすべてのネットワークに適切な情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups1
-- the following five groups are mutually exclusive; at most -- one of these groups is implemented for any interface
-- 以下の5つのグループが互いに排他的です。 高々、これらのグループの1つはどんなインタフェースにも実装されます。
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to non-high speed, character-oriented or
fixed-length-transmission network interfaces. (Non-
high speed interfaces transmit and receive at speeds
less than or equal to 20,000,000 bits/second.)"
::= { ifGroups 2 }
ifFixedLengthGroup OBJECT-GROUP OBJECTS、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、STATUSの現在の記述、「非高速か、キャラクタ指向の、または、長さの送電網を固定しているインタフェースに特定の情報を提供するオブジェクトの収集。」 (非高速なインタフェースは2000万ビット/秒以下の速度で送受信されます。)" ::= ifGroups2
ifHCFixedLengthGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to high speed (greater than 20,000,000
bits/second) character-oriented or fixed-length-
transmission network interfaces."
::= { ifGroups 3 }
ifHCFixedLengthGroup OBJECT-GROUP OBJECTS、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、「オブジェクトが高速(2000万ビット/秒以上)キャラクタ指向の、または、固定長さのトランスミッションのネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups3
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifPacketGroupオブジェクト群対象、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts
McCloghrie & Kastenholz [Page 51] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[51ページ]RFC1573はグループ発展1994年1月に連結します。
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to non-high speed, packet-oriented network
interfaces. (Non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second.)"
::= { ifGroups 4 }
ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode 「オブジェクトが非高速で、パケット指向のネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 (非高速インタフェースは2000万ビット/秒以下の速度で送受信されます。)" ::= ifGroups4
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to high speed (greater than 20,000,000
bits/second but less than or equal to 650,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 5 }
ifHCPacketGroupオブジェクト群対象、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode; 「オブジェクトが高速(2000万ビット以上/秒にもかかわらず、6億5000万ビット/秒以下)パケット指向のネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups5
ifVHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
ifHCInBroadcastPkts, ifHCOutUcastPkts,
ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to higher speed (greater than 650,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 6 }
ifVHCPacketGroupオブジェクト群対象、ifHCInUcastPkts、ifHCInMulticastPkts、ifHCInBroadcastPkts、ifHCOutUcastPkts、ifHCOutMulticastPkts、ifHCOutBroadcastPkts、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode; 「オブジェクトが、より高い速度(6億5000万ビット/秒以上)のパケット指向のネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups6
McCloghrie & Kastenholz [Page 52] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[52ページ]RFC1573はグループ発展1994年1月に連結します。
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
ifRcvAddressGroup OBJECT-GROUP OBJECTS、ifRcvAddressStatus、ifRcvAddressType、「オブジェクトが倍数の情報を提供する収集はインタフェースが受けるものを扱う」STATUSの現在の記述。 ::= ifGroups7
ifTestGroup OBJECT-GROUP
OBJECTS { ifTestId, ifTestStatus, ifTestType,
ifTestResult, ifTestCode, ifTestOwner }
STATUS current
DESCRIPTION
"A collection of objects providing the ability to
invoke tests on an interface."
::= { ifGroups 8 }
ifTestGroup OBJECT-GROUP OBJECTS、ifTestId、ifTestStatus、ifTestType、ifTestResult、ifTestCode、ifTestOwner、「オブジェクトが呼び出す能力を提供する収集はインタフェースでテストする」STATUSの現在の記述。 ::= ifGroups8
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 9 }
ifStackGroup OBJECT-GROUP OBJECTS ifStackStatus、「オブジェクトがMIB-IIのレイヤリングの情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups9
END
終わり
7. Acknowledgements
7. 承認
This memo has been produced by the IETF's Interfaces MIB Working Group.
このメモはIETFのInterfaces MIB作業部会によって製作されました。
The initial proposal to the working group was the result of conversations and discussions with many people, including at least the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop.
ワーキンググループへの最初の提案は、会話の結果と少なくとも以下を含む多くの人々との議論でした: フレッド・ベイカー、テッド・ブルンナー、チャック・デーヴィン、ジェレミー・グリーン、マーシャル・ローズ、カイTesink、およびディーンThroop。
8. References
8. 参照
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[1]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」、RFC1442、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[2] Galvin, J., and K. McCloghrie, "Administrative Model for version
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April 1993.
[2] ガルビン、J.、およびK.McCloghrie、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための管理Model」、RFC1445、Trusted情報システム、ヒューズLAN Systems(1993年4月)。
McCloghrie & Kastenholz [Page 53] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[53ページ]RFC1573はグループ発展1994年1月に連結します。
[3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[3] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためにOperationsについて議定書の中で述べます」、RFC1448、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学、1993年4月。
[4] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[4]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地--、MIB-II、」、STD17、RFC1213、ヒューズLAN Systems国際パフォーマンスSystems、3月1991日
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[5] SNMPが研究するケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、RFC1157、国際言語運用機構、国際言語運用機構(MITコンピュータサイエンス研究所)は1990がそうするかもしれません。
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[6] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
1229, Hughes LAN Systems, May 1991.
[7] McCloghrie(K.、「ジェネリックインタフェースMIBへの拡大」、RFC1229、ヒューズLANシステム)は1991がそうするかもしれません。
[8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
Conventions for version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[8]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」、RFC1443、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
McCloghrie & Kastenholz [Page 54] RFC 1573 Interfaces Group Evolution January 1994
McCloghrie&Kastenholz[54ページ]RFC1573はグループ発展1994年1月に連結します。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Authors' Addresses
10. 作者のアドレス
Keith McCloghrie Hughes LAN Systems 1225 Charleston Rd, Mountain View, Ca 94043
キースMcCloghrieヒューズLANシステム1225チャールストン、マウンテンビュー、第Ca94043
Phone: 415-966-7934 EMail: kzm@hls.com
以下に電話をしてください。 415-966-7934 メールしてください: kzm@hls.com
Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845
ノースアンドーバー、フランクKastenholz FTPソフトウェア2本通りマサチューセッツ州 米国01845
Phone: (508)685-4000 EMail: kasten@ftp.com
以下に電話をしてください。 (508)685-4000 メールしてください: kasten@ftp.com
McCloghrie & Kastenholz [Page 55]
McCloghrie&Kastenholz[55ページ]
一覧
スポンサーリンク
