RFC2074 日本語訳
2074 Remote Network Monitoring MIB Protocol Identifiers. A. Bierman,R. Iddon. January 1997. (Format: TXT=81262 bytes) (Obsoleted by RFC2895) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bierman
Request for Comments: 2074 Cisco Systems
Category: Standards Track R. Iddon
AXON Networks,Inc.
January 1997
Biermanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2074年のシスコシステムズカテゴリ: 標準化過程R.Iddon軸索ネットワーク、株式会社1997年1月
Remote Network Monitoring MIB Protocol Identifiers
リモートネットワーク監視MIBプロトコル識別子
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 .................................................... 3 2 The SNMP Network Management Framework ........................... 3 2.1 Object Definitions ............................................ 3 3 Overview ........................................................ 3 3.1 Terms ......................................................... 4 3.2 Relationship to the Remote Network Monitoring MIB ............. 6 3.3 Relationship to the Other MIBs ................................ 6 4 Protocol Identifier Encoding .................................... 7 4.1 ProtocolDirTable INDEX Format Examples ........................ 9 4.2 Protocol Identifier Macro Format .............................. 10 4.2.1 Mapping of the Protocol Name ................................ 12 4.2.2 Mapping of the VARIANT-OF Clause ............................ 13 4.2.3 Mapping of the PARAMETERS Clause ............................ 13 4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 14 4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 15 4.2.4 Mapping of the ATTRIBUTES Clause ............................ 15 4.2.5 Mapping of the DESCRIPTION Clause ........................... 15 4.2.6 Mapping of the CHILDREN Clause .............................. 16 4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 16 4.2.8 Mapping of the DECODING Clause .............................. 16 4.2.9 Mapping of the REFERENCE Clause ............................. 17 4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 17 5 Protocol Identifier Macros ...................................... 18 5.1 Base Identifier Encoding ...................................... 18 5.1.1 Protocol Identifier Functions ............................... 19 5.1.1.1 Function 0: No-op ......................................... 19 5.1.1.2 Function 1: Protocol Wildcard Function .................... 19 5.2 Base Layer Protocol Identifiers ............................... 20 5.2.1 Ether2 Encapsulation ........................................ 21
1つの序論… 3 2、SNMPネットワークマネージメントフレームワーク… 3 2.1 オブジェクト定義… 3 3概要… 3 3.1の用語… 4 3.2 リモートとの関係はモニターしているMIBをネットワークでつなぎます… 6 他のMIBsとの3.3関係… 6 4は識別子コード化について議定書の中で述べます… 7 4.1 ProtocolDirTableは形式の例に索引をつけます… 9 4.2 識別子マクロ形式について議定書の中で述べてください… 10 4.2 プロトコル名に関する.1マッピング… 12 4.2 .2マッピング、異形、-、節… 13 4.2 パラメタ節に関する.3マッピング… 13 4.2 .3 'countsFragments(0)'ビットの.1マッピング… 14 4.2 .3 'tracksSessions(1)'ビットの.2マッピング… 15 4.2 属性節に関する.4マッピング… 15 4.2 記述節に関する.5マッピング… 15 4.2 子供節に関する.6マッピング… 16 4.2 アドレス形式節に関する.7マッピング… 16 4.2 解読節に関する.8マッピング… 16 4.2 参照節に関する.9マッピング… 17 4.2 プロトコル識別子を評価する.10が索引をつけます… 17 5 識別子マクロについて議定書の中で述べてください… 18 5.1 識別子コード化を基礎づけてください… 18 5.1 .1 識別子機能について議定書の中で述べてください… 19 5.1 .1 .1 機�%%BODY%%: オプアートがありません… 19 5.1 .1 .2 機能1: ワイルドカード機能について議定書の中で述べてください… 19 5.2 層のプロトコル識別子を基礎づけてください… 20 5.2 .1 Ether2カプセル化… 21
Bierman & Iddon Standards Track [Page 1] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[1ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.2.2 LLC Encapsulation ........................................... 22 5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 23 5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 24 5.2.5 IANA Assigned Protocols ..................................... 25 5.2.5.1 IANA Assigned Protocol Identifiers ........................ 27 5.3 L3: Children of Base Protocol Identifiers ..................... 27 5.3.1 IP .......................................................... 28 5.3.2 IPX ......................................................... 29 5.3.3 ARP ......................................................... 30 5.3.4 IDP ......................................................... 30 5.3.5 AppleTalk ARP ............................................... 31 5.3.6 AppleTalk ................................................... 31 5.4 L4: Children of L3 Protocols .................................. 32 5.4.1 ICMP ........................................................ 32 5.4.2 TCP ......................................................... 32 5.4.3 UDP ......................................................... 33 5.5 L5: Application Layer Protocols ............................... 33 5.5.1 FTP ......................................................... 33 5.5.1.1 FTP-DATA .................................................. 33 5.5.1.2 FTP Control ............................................... 34 5.5.2 Telnet ...................................................... 34 5.5.3 SMTP ........................................................ 34 5.5.4 DNS ......................................................... 35 5.5.5 BOOTP ....................................................... 35 5.5.5.1 Bootstrap Server Protocol ................................. 35 5.5.5.2 Bootstrap Client Protocol ................................. 35 5.5.6 TFTP ........................................................ 36 5.5.7 HTTP ........................................................ 36 5.5.8 POP3 ........................................................ 36 5.5.9 SUNRPC ...................................................... 37 5.5.10 NFS ........................................................ 38 5.5.11 SNMP ....................................................... 38 5.5.11.1 SNMP Request/Response .................................... 38 5.5.11.2 SNMP Trap ................................................ 39 6 Acknowledgements ................................................ 39 7 References ...................................................... 40 8 Security Considerations ......................................... 43 9 Authors' Addresses .............................................. 43
5.2.2 LLCカプセル化… 22 5.2 .3 LLC(OUI=000)カプセル化の上で折ってください… 23 5.2 .4 LLC(OUI!=000)カプセル化の上で折ってください… 24 5.2 .5 IANAはプロトコルを割り当てました… 25 5.2 .5 .1 IANAはプロトコル識別子を割り当てました… 27 5.3L3: 基地の子供は識別子について議定書の中で述べます… 27 5.3.1IP… 28 5.3 .2IPX… 29 5.3 .3アルプ… 30 5.3 .4IDP… 30 5.3 .5 AppleTalk ARP… 31 5.3 .6のAppleTalk… 31 5.4L4: L3プロトコルの子供… 32 5.4 .1ICMP… 32 5.4 .2TCP… 32 5.4 .3UDP… 33 5.5L5: 応用層プロトコル… 33 5.5 .1FTP… 33 5.5 .1 .1のFTPデータ… 33 5.5 .1 .2 FTPコントロール… 34 5.5 .2telnet… 34 5.5 .3SMTP… 34 5.5 .4DNS… 35 5.5 .5BOOTP… 35 5.5 .5 .1 サーバプロトコルを独力で進んでください… 35 5.5 .5 .2 クライアントプロトコルを独力で進んでください… 35 5.5 .6TFTP… 36 5.5 .7HTTP… 36 5.5 .8POP3… 36 5.5 .9SUNRPC… 37 5.5 .10NFS… 38 5.5 .11SNMP… 38 5.5 .11 .1 SNMP要求/応答… 38 5.5 .11 .2 SNMPは捕らえます… 39 6つの承認… 39 7つの参照箇所… 40 8 セキュリティ問題… 43 9人の作者のアドレス… 43
Bierman & Iddon Standards Track [Page 2] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[2ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
1. Introduction
1. 序論
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. Although related to the original Remote Network Monitoring MIB [RFC1757], this document refers only to objects found in the RMON-2 MIB.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の実験的な部分(MIB)を定義します。 特に、それはRemote Network Monitoring MIBバージョン2[RMON2]で管理された異なったプロトコルカプセル化を特定するのに必要であるアルゴリズムを説明します。 オリジナルのRemote Network Monitoring MIB[RFC1757]に関連されますが、このドキュメントはRMON-2 MIBで見つけられたオブジェクトだけについて言及します。
2. The SNMP Network Management Framework
2. SNMPネットワークマネージメントフレームワーク
The SNMP Network Management Framework presently consists of three major components. They are:
SNMP Network Management Frameworkは現在、3個の主要コンポーネントから成ります。 それらは以下の通りです。
o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
describing and naming objects for the purpose of management.
o RFC1902[RFC1902]で説明されたSMI--メカニズムは説明と命名に管理の目的のためのオブジェクトを使用しました。
o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
objects for the Internet suite of protocols.
o MIB-II、STD17、RFC1213[RFC1213]--プロトコルのインターネットスイートへの管理オブジェクトの巻き癖。
o the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905],
- the protocol for accessing managed information.
o プロトコル、STD15、RFC1157[RFC1157]、そして/または、RFC1905[RFC1905]--アクセスのためのプロトコルは情報を管理しました。
Textual conventions are defined in RFC 1903 [RFC1903], and conformance statements are defined in RFC 1904 [RFC1904].
原文のコンベンションはRFC1903[RFC1903]で定義されます、そして、順応声明はRFC1904[RFC1904]で定義されます。
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
Frameworkは、新しいオブジェクトが実験と評価の目的のために定義されるのを可能にします。
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 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. Overview
3. 概要
The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
[RMON2]が階層的で使用するRMON-2 MIBは、protocolDirTableで個々のプロトコルカプセル化をグローバルに特定するためにOCTET STRINGsをフォーマットしました。
Bierman & Iddon Standards Track [Page 3] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[3ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
This guide contains algorithms and examples of protocol identifier encapsulations for use as INDEX values in the protocolDirTable.
INDEXがprotocolDirTableで評価するようにこのガイドは使用のためのプロトコル識別子カプセル化に関するアルゴリズムと例を含みます。
This document is not intended to be an authoritative reference on the protocols described herein. Refer to the Official Internet Standards document [RFC1800], the Assigned Numbers document [RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete and authoritative protocol information.
このドキュメントはここに説明されたプロトコルに関する正式の参照であることを意図しません。 完全で正式のプロトコル情報についてOfficialインターネットStandardsドキュメント[RFC1800]、Assigned民数記ドキュメント[RFC1700]、または他の適切なRFCs、IEEEドキュメントなどを参照してください。
3.1. Terms
3.1. 用語
Several terms are used throughout this document, as well as in the RMON-2 MIB [RMON2], that should be introduced:
このドキュメント中と、そして、RMON-2 MIB[RMON2]でいくつかの用語を使用して、それを導入するべきです:
layer-identifier:
An octet string fragment representing a particular protocol
encapsulation layer. A string fragment identifying a particular
protocol encapsulation layer. This string is exactly four octets,
(except for the 'vsnap' base-layer identifier, which is exactly
eight octets) encoded in network byte order. A particular protocol
encapsulation can be identified by starting with a base layer
encapsulation (see the 'Base Protocol Identifiers' section for more
detail), and following the encoding rules specified in the CHILDREN
clause and assignment section for that layer. Then repeat for each
identified layer in the encapsulation. (See section 4.2.10
'Evaluating a Protocol-Identifier INDEX' for more detail.)
層識別子: 特定のプロトコルカプセル化層を表す八重奏ストリング断片。 特定のプロトコルカプセル化層を特定するストリング断片。 このストリングはまさにネットワークバイトオーダーでコード化された(まさに8つの八重奏である'vsnap'基層識別子を除いて)4つの八重奏です。 基層カプセル化(その他の詳細に関して'基地のプロトコルIdentifiers'セクションを見る)から始まることによって、特定のプロトコルカプセル化を特定できるでしょう、そして、符号化規則に従うのはCHILDREN節と課題部でその層に指定しました。 その時、それぞれの特定された層には、カプセル化で繰り返してください。 (その他の詳細のために'プロトコル識別子INDEXを評価し'て、セクション4.2.10を見てください。)
protocol:
A particular protocol layer, as specified by encoding rules in this
document. Usually refers to a single layer in a given
encapsulation. Note that this term is sometimes used in the RMON-2
MIB [RMON2] to name a fully-specified protocol-identifier string.
In such a case, the protocol-identifier string is named for its
upper-most layer. A named protocol may also refer to any
encapsulation of that protocol.
以下について議定書の中で述べてください。 符号化規則で本書では指定されるような特定のプロトコル層。 通常、与えられたカプセル化で単一層について言及します。 今期が完全に指定されたプロトコル識別子ストリングを命名するのにRMON-2 MIB[RMON2]で時々使用されることに注意してください。 このような場合には、プロトコル識別子ストリングは最高の層にちなんで命名されます。 また、命名されたプロトコルはそのプロトコルのどんなカプセル化についても言及するかもしれません。
protocol-identifier string:
An octet string representing a particular protocol encapsulation,
as specified by encoding rules in this document. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
protocol-identifier string is composed of one or more layer-
identifiers.
プロトコル識別子ストリング: 符号化規則で本書では指定されるように特定のプロトコルカプセル化を表す八重奏ストリング。 protocolDirIDが反対するようにこのストリングはRMON-2 MIB[RMON2]で特定されます。 プロトコル識別子ストリングは1つ以上の層の識別子で構成されます。
Bierman & Iddon Standards Track [Page 4] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[4ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
protocol-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. The macro serves several
purposes:
プロトコル識別子マクロ: 特定のプロトコルについて説明するフォーマット済みのテキストのグループはRMON-2 MIB[RMON2]の中で使用されるように層にされます。 マクロはいくつかの目的に役立ちます:
- Name the protocol for use within the RMON-2 MIB [RMON2].
- Describe how the protocol is encoded into an octet string.
- Describe how child protocols are identified (if applicable),
and encoded into an octet string.
- Describe which protocolDirParameters are allowed for the protocol.
- Describe how the associated protocolDirType object is encoded
for the protocol.
- Provide reference(s) to authoritative documentation for the
protocol.
- RMON-2 MIBの中の使用のためのプロトコルを[RMON2]と命名してください。 - プロトコルがどうコード化されるかを八重奏ストリングに説明してください。 - 子供プロトコルがどう特定されて(適切であるなら)、コード化されるかを八重奏ストリングに説明してください。 - どのprotocolDirParametersがプロトコルのために許容されているか説明してください。 - 関連protocolDirTypeオブジェクトがプロトコルのためにどうコード化されるかを説明してください。 - 正式のドキュメンテーションのプロトコルの参照を提供してください。
protocol-variant-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. This protocol is a variant
of a well known encapsulation that may be present in the
protocolDirTable. This macro is used to document the IANA
assigned protocols, which are needed to identify protocols which
cannot be practically identified by examination of 'appropriate
network traffic' (e.g. the packets which carry them). All other
protocols (which can be identified by examination of appropriate
network traffic) should be documented using the protocol-identifier
macro. A protocol-variant-identifier is documented using the
protocol-variant version of the protocol-identifier macro.
プロトコル異形識別子マクロ: 特定のプロトコルについて説明するフォーマット済みのテキストのグループはRMON-2 MIB[RMON2]の中で使用されるように層にされます。 このプロトコルはprotocolDirTableの存在するかもしれないよく知られているカプセル化の異形です。 このマクロは、'適切なネットワークトラフィック'(例えば、それらを運ぶパケット)の試験で実際に特定できないプロトコルを特定するのに必要であるプロトコルが割り当てられたIANAを記録するのに使用されます。 他のすべてのプロトコル(適切なネットワークトラフィックの試験で特定できる)が、プロトコル識別子マクロを使用することで記録されるべきです。 プロトコル異形識別子は、プロトコル識別子マクロのプロトコル異形バージョンを使用することで記録されます。
protocol-parameter:
A single octet, corresponding to a specific layer-identifier in the
protocol-identifier. This octet is a bit-mask indicating special
functions or capabilities that this agent is providing for the
corresponding protocol.
プロトコルパラメタ: プロトコル識別子の特定の層識別子に対応するただ一つの八重奏。 この八重奏は特別な機能を示すか、このエージェントが対応するプロトコルに提供している能力に少しマスクをかけることです。
protocol-parameters string:
An octet string, which contains one protocol-parameter for each
layer-identifier in the protocol-identifier. See the section
'Mapping of the PARAMETERS Clause' for more detail. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
object.
プロトコルパラメタは以下を結びます。 八重奏ストリング。(そのストリングはプロトコル識別子のそれぞれの層識別子あたり1つのプロトコルパラメタを含みます)。 その他の詳細に関して'PARAMETERS Clauseに関するマッピング'というセクションを見てください。 protocolDirParametersが反対するようにこのストリングはRMON-2 MIB[RMON2]で特定されます。
protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair
that have been converted to an INDEX value, according to the
encoding rules in in section 7.7 of RFC 1902 [RFC1902].
protocolDirTableは索引をつけます: 八重奏がRFC1902[RFC1902]のセクション7.7で符号化規則によると、INDEX値に変換された組を結ぶプロトコル識別子とプロトコルパラメタ。
Bierman & Iddon Standards Track [Page 5] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[5ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
pseudo-protocol:
A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings.
疑似プロトコル: コンベンションかアルゴリズムがプロトコル識別子ストリングをコード化する目的に中だけでこのドキュメントを使用しました。
3.2. Relationship to the Remote Network Monitoring MIB
3.2. リモートネットワーク監視MIBとの関係
This document is intended to identify possible string values for the OCTET STRING objects protocolDirID and protocolDirParameters. Tables in the new Protocol Distribution, Host, and Matrix groups use a local INTEGER INDEX, in order to remain unaffected by changes in this document. Only the protocolDirTable uses the strings (protocolDirID and protocolDirParameters) described in this document.
このドキュメントがOCTET STRINGオブジェクトのprotocolDirIDとprotocolDirParametersのために可能なストリング値を特定することを意図します。 新しいプロトコルDistribution、Host、およびマトリクスグループにおけるテーブルは地方のINTEGER INDEXを使用します、変化で本書では影響を受けないままで残るために。 protocolDirTableだけが本書では説明されたストリング(protocolDirIDとprotocolDirParameters)を使用します。
This document is not intended to limit the protocols that may be identified for counting in the RMON-2 MIB. Many protocol encapsulations, not explicitly identified in this document, may be present in an actual implementation of the protocolDirTable. Also, implementations of the protocolDirTable may not include all the protocols identified in the example section below.
このドキュメントがRMON-2 MIBで数えるために特定されるかもしれないプロトコルを制限することを意図しません。 多くの明らかに本書では特定されなかったプロトコルカプセル化がprotocolDirTableの実際の実装で存在しているかもしれません。 また、protocolDirTableの実装は下の例の部で特定されたすべてのプロトコルを含まないかもしれません。
This document is intentionally separated from the MIB objects to allow frequent updates to this document without any republication of MIB objects. Protocol Identifier macros submitted from the RMON working group and community at large (to the RMONMIB WG mailing list at 'rmonmib@cisco.com') will be collected and added to this document.
このドキュメントは、MIBオブジェクトの少しも再刊なしでこのドキュメントに頻繁なアップデートを許すために故意にMIBオブジェクトと切り離されます。 RMONワーキンググループと一般社会(' rmonmib@cisco.com 'のRMONMIB WGメーリングリストへの)から提出されたプロトコルIdentifierマクロは、このドキュメントに集められて、追加されるでしょう。
Macros submissions will be collected in the IANA's MIB files under the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the RMONMIB working group mailing list message archive file "ftp://ftp.cisco.com/ftp/rmonmib/rmonmib".
マクロ差出は" ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/ "というディレクトリの下におけるIANAのMIBファイルの中と、そして、" ftp://ftp.cisco.com/ftp/rmonmib/rmonmib "というRMONMIBワーキンググループメーリングリストメッセージアーカイブファイルに集められるでしょう。
This document does not discuss auto-discovery and auto-population of the protocolDirTable. This functionality is not explicitly defined by the RMON standard. An agent should populate the directory with 'interesting' protocols--depending on the intended applications.
このドキュメントはprotocolDirTableの自動発見と自動人口について議論しません。 この機能性はRMON規格によって明らかに定義されません。 意図しているアプリケーションによって、エージェントは'おもしろい'プロトコルでディレクトリに居住するべきです。
3.3. Relationship to the Other MIBs
3.3. 他のMIBsとの関係
The RMON Protocol Identifiers document is intended for use with the protocolDirTable within the RMON MIB. It is not relevant to any other MIB, or intended for use with any other MIB.
RMONプロトコルIdentifiersドキュメントは使用のためにRMON MIBの中のprotocolDirTableと共に意図します。 それは、いかなる他のMIBにも関連しない、またいかなる他のMIBとの使用のためにも意図していません。
Bierman & Iddon Standards Track [Page 6] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[6ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
4. Protocol Identifier Encoding
4. プロトコル識別子コード化
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable- length string is converted to an OBJECT IDENTIFIER fragment, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index fragments are simply concatenated. (Refer to figures 1a - 1d below for more detail.)
protocolDirTableは2OCTET STRINGs、protocolDirID、およびprotocolDirParametersによって索引をつけられます。 テーブルインデックスをコード化するために、それぞれの可変長さのストリングはOBJECT IDENTIFIER断片に変換されます、RFC1902[RFC1902]のセクション7.7の符号化規則によると。 そして、インデックス断片は単に連結されます。 (数字の1aを参照してください--その他の詳細のための以下の1d)
The first OCTET STRING (protocolDirID) is composed of one or more 4- octet "layer-identifiers". The entire string uniquely identifies a particular protocol encapsulation tree. The second OCTET STRING, (protocolDirParameters) which contains a corresponding number of 1- octet protocol-specific parameters, one for each 4-octet layer- identifier in the first string.
最初のOCTET STRING(protocolDirID)は1 4八重奏「層識別子」で構成されます。 全体のストリングは唯一特定のプロトコルカプセル化木を特定します。 第2OCTET STRING、対応する数の1つの八重奏のプロトコル特有のパラメタ、各4八重奏あたり1つを含む(protocolDirParameters)が最初のストリングの識別子を層にします。
A protocol layer is normally identified by a single 32-bit value. Each layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of the 32-bit value in network byte order. If a particular protocol layer cannot be encoded into 32 bits, (except for the 'vsnap' base layer) then it must be defined as a 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
通常、プロトコル層はただ一つの32ビットの値によって特定されます。 'それぞれの層識別子は4つのサブコンポーネント[a.b.c.d]としてProtocolDirID OCTET STRING INDEXでコード化されます、どこ'a'--、'ネットワークバイトオーダーにおける、32ビットの価値の各バイトを表してくださいか。 特定のプロトコル層をコード化できないなら、32ビット、それがそうしなければならない('vsnap'基層を除いた)その時まで'ianaAssigned'プロトコルと定義されてください(プロトコルが割り当てられたIANAに関する詳細に関して以下を見てください)。
The following figures show the differences between the OBJECT IDENTIFIER and OCTET STRING encoding of the protocol identifier string.
以下の数字には、プロトコル識別子ストリングのOBJECT IDENTIFIERとOCTET STRINGコード化の差異があります。
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
図1a protocolDirTableインデックス形式-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
+---+--------------------------+---+---------------+ | c!| c!protocolDir| | n! protocolDirID| n!Parameters| | t!| t!| +---+--------------------------+---+---------------+
Bierman & Iddon Standards Track [Page 7] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[7ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
図1b protocolDirTable八重奏記号列の書式------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirID+----------------------------------------+ | | | 4*N八重奏| | | +----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
protocolDirParameters+----------+ | | | N八重奏| | | +----------+
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
図1c protocolDirTableインデックス形式の例-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count
protocolDirID protocolDirParameters+---+--------+--------+--------+--------+---+---+---+---+---+ | c| proto| proto| proto| proto| c|平価|平価|平価|平価| | n| ベース| L3| L4| L5| n|Ba| L3| L4| L5| | t|(+ 旗)| | | | t|se| | | | +---+--------+--------+--------+--------+---+---+---+---+---+ subOID| 1 | 4か8| 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | カウント
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
All other protocol layers are either encoded into 4 sub-identifiers
or encoded as a 'ianaAssigned' protocol.
Nが命名されたプロトコルの全体のカプセル化に必要であるプロトコル層の識別子の数であるところ。 'vsnap'基層識別子が8つのサブ識別子にコード化されるというメモ、他のプロトコルが層にするAllは4つのサブ識別子にコード化されるか、または'ianaAssigned'プロトコルとしてコード化されます。
Bierman & Iddon Standards Track [Page 8] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[8ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
図1d protocolDirTable八重奏記号列の書式の例--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 or 8 | 4 | 4 | 4 | count
protocolDirID+--------+--------+--------+--------+ | proto| proto| proto| proto| | ベース| L3| L4| L5| | | | | | +--------+--------+--------+--------+ 八重奏| 4か8| 4 | 4 | 4 | カウント
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
|1/2| 1 | 1 | 1 | count
protocolDirParameters+---+---+---+---+ |平価|平価|平価|平価| |Ba| L3| L4| L5| |se| | | | +---+---+---+---+ 八重奏|1/2| 1 | 1 | 1 | カウント
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters
sub-identifiers.
Nが命名されたプロトコルの全体のカプセル化に必要であるプロトコル層の識別子の数であるところ。 'vsnap'基層識別子が8つのprotocolDirIDサブ識別子と2つのprotocolDirParametersサブ識別子にコード化されることに注意してください。
Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 3.5 of RFC 1902 [RFC1902].
この例は、4が実際にはプロトコルをカプセル化したのを示しますが、どんな非ゼロ番号の層識別子も、現在であって、単にOBJECT IDENTIFIER長さの制限で理論的に限られるかもしれません、RFC1902[RFC1902]のセクション3.5で指定されるように。
Note that these two strings would not be concatenated together if ever returned in a GetResponse PDU, since they are different MIB objects. However, protocolDirID and protocolDirParameters are not currently readable MIB objects.
今までにGetResponse PDUで返すならこれらの2個のストリングを一緒に連結しないことに注意してください、それらが異なったMIBオブジェクトであるので。 しかしながら、protocolDirIDとprotocolDirParametersは現在読み込み可能なMIBオブジェクトではありません。
4.1. ProtocolDirTable INDEX Format Examples
4.1. ProtocolDirTableインデックス形式の例
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- HTTP。 断片がIPとether2.ip.tcp.www-http=16.0.0.0より上で.1を数えた、.0、.0、.8、.0、.0、.0、.0、.6、.0、.0、.0、.80、.4、.0、.1、.0、.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNAP snap.ip.udp.snmp=16.0.0の上のUDP/IPの上のSNMP、.0、.3、.0、.0、.8、.0、.0、.0、.0、.17、.0、.0、.0、.161、.4、.0、.0、.0、.0
Bierman & Iddon Standards Track [Page 9] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[9ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNAP snap.ipx.snmp=12.0.0の上のIPXの上のSNMP、.0、.3、.0、.0、.129、.55、.0、.0、.144、.15、.3、.0、.0、.0
-- SNMP over IPX over raw8023
-- ianaAssigned(ipxOverRaw8023(1)).snmp =
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
-- raw8023の上のIPXの上のSNMP--、ianaAssigned、(ipxOverRaw8023(1)).snmp=12.0.0.0、.5、.0、.0、.0、.1、.0、.0、.155、.15、.3、.0、.0、.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0
-- LLC llc.ipx=8.0.0の上のIPX、.0、.2、.0、.224、.224、.3、.2、.0、.0
-- SNMP over UDP/IP over any link layer
-- wildcard-ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- いずれも上のUDP/IPの上のSNMPがワイルドカード-ether2.ip.udp.snmp16.1に層をリンクする、.0、.0、.1、.0、.0、.8、.0、.0、.0、.0、.17、.0、.0、.0、.161、.4、.0、.0、.0、.0
-- IP over any link layer; base encoding is IP over ether2
-- wildcard-ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- どんなリンクレイヤの上のIP。 ベースコード化がワイルドカード-ether2.ip8.1にether2の上のIPである、.0、.0、.1、.0、.0、.8、.0、.2、.0、.0
-- AppleTalk Phase 2 over ether2
-- ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- ether2の上のAppleTalk Phase2--、ether2.atalk8.0.0、.0、.1、.0、.0、.128、.155、.2、.0、.0
-- AppleTalk Phase 2 over vsnap
-- vsnap(apple).atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
-- vsnap--(りんご).atalk12.0.0.0をvsnapする上のAppleTalk Phase2、.4、.0、.8、.0、.7、.0、.0、.128、.155、.3、.0、.0、.0
4.2. Protocol Identifier Macro Format
4.2. プロトコル識別子マクロ形式
The following example is meant to introduce the protocol-identifier macro. (The syntax is not quite ASN.1.) This macro is used to represent both protocols and protocol-variants.
以下の例はプロトコル識別子マクロを導入することになっています。 (構文は全くASN.1であるというわけではない。) このマクロは、プロトコルとプロトコル異形の両方を表すのに使用されます。
If the 'VariantOfPart' component of the macro is present, then the macro represents a protocol-variant instead of a protocol. A protocol- variant-identifier is used only for IANA assigned protocols, enumerated under the 'ianaAssigned' base-layer.
マクロの'VariantOfPart'コンポーネントが存在しているなら、マクロはプロトコルの代わりにプロトコル異形を表します。 プロトコル異形識別子は'ianaAssigned'基層の下で列挙されたプロトコルが割り当てられたIANAにだけ使用されます。
Bierman & Iddon Standards Track [Page 10] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[10ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
RMON-PROTOCOL-IDENTIFIER MACRO ::=
BEGIN
PIMacroName "PROTOCOL-IDENTIFIER"
VariantOfPart
"PARAMETERS" ParamPart
"ATTRIBUTES" AttrPart
"DESCRIPTION" Text
ChildDescrPart
AddrDescrPart
DecodeDescrPart
ReferPart
"::=" "{" EncapsPart "}"
RMON-プロトコル識別子マクロ:、:= 「PIMacroName「プロトコル識別子」VariantOfPart「パラメタ」ParamPart「属性」AttrPart「記述」テキストChildDescrPart AddrDescrPart DecodeDescrPart ReferPartを始めてください」:、:=「「"EncapsPart"、」、」
PIMacroName ::=
identifier
PIMacroName:、:= 識別子
VariantOfPart ::=
"VARIANT-OF" identifier | empty
VariantOfPart:、:= "VARIANT-OF"識別子| 空になってください。
ParamPart ::=
"{" ParamList "}"
ParamPart:、:= 「"ParamList"、」
ParamList ::=
Params | empty
ParamList:、:= Params| 空になってください。
Params ::=
Param | Params "," Param
Params:、:= Param| 」 "Params"、Param
Param ::=
identifier "(" nonNegativeNumber ")"
Param:、:= 「("nonNegativeNumber")」という識別子
AttrPart ::=
"{" AttrList "}"
AttrPart:、:= 「"AttrList"、」
AttrList ::=
Attrs | empty
AttrList:、:= Attrs| 空になってください。
Attrs ::=
Attr | Attrs "," Attr
Attrs:、:= Attr| 」 "Attrs"、Attr
Attr ::=
identifier "(" nonNegativeNumber ")"
Attr:、:= 「("nonNegativeNumber")」という識別子
ChildDescrPart ::=
"CHILDREN" Text | empty
ChildDescrPart:、:= 「子供」というテキスト| 空になってください。
AddrDescrPart ::=
"ADDRESS-FORMAT" Text | empty
AddrDescrPart:、:= 「アドレス形式」というテキスト| 空になってください。
Bierman & Iddon Standards Track [Page 11] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[11ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
DecodeDescrPart ::=
"DECODING" Text | empty
DecodeDescrPart:、:= 「解読」というテキスト| 空になってください。
ReferPart ::=
"REFERENCE" Text | empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
EncapsPart ::=
"{" Encaps "}"
EncapsPart:、:= 「"Encapsする"」です。
Encaps ::=
Encap | Encaps "," Encap
Encaps:、:= Encap| 」 "Encaps"、Encap
Encap ::=
BaseEncap | NormalEncap | VsnapEncap | IanaEncap
Encap:、:= BaseEncap| NormalEncap| VsnapEncap| IanaEncap
BaseEncap ::=
nonNegativeNumber
BaseEncap:、:= nonNegativeNumber
NormalEncap ::=
identifier nonNegativeNumber
NormalEncap:、:= 識別子nonNegativeNumber
VsnapEncap ::=
identifier "(" nonNegativeNumber ")" nonNegativeNumber
VsnapEncap:、:= 「("nonNegativeNumber")」という識別子nonNegativeNumber
IanaEncap ::=
"ianaAssigned" nonNegativeNumber
| "ianaAssigned" identifier
| "ianaAssigned" identifier "(" nonNegativeNumber ")"
IanaEncap:、:= nonNegativeNumberを「ianaAssignedしました」。| 識別子を「ianaAssignedしました」。| 「("nonNegativeNumber")」という識別子を「ianaAssignedしました」。
Text ::=
"""" string """"
END
テキスト:、:= 「「「「ストリング、「「「「終わってください」
4.2.1. Mapping of the Protocol Name
4.2.1. プロトコル名に関するマッピング
The 'PIMacroName' value should be a lower-case ASCII string, and contain the name or acronym identifying the protocol. NMS applications may treat protocol names as case-insensitive strings, and agent implementations must make sure the protocolDirTable does not contain any instances of the protocolDirDescr object which differ only in the case of one of more letters (if the identifiers are intended to represent different protocols).
'PIMacroName'値は、小文字のASCIIストリングであり、プロトコルを特定する名前か頭文字語を含むべきです。 NMSアプリケーションは大文字と小文字を区別しないストリングとしてプロトコル名を扱うかもしれません、そして、実装が確実にprotocolDirTableを作らなければならないエージェントは、より多くの手紙の1つの場合だけにおいて異なるprotocolDirDescrオブジェクトのどんなインスタンスも含みません(識別子が異なったプロトコルを表すことを意図するなら)。
It is possible that different encapsulations of the same protocol (which are represented by different entries in the protocolDirTable) will be assigned the same protocol name.
同じプロトコル名が同じプロトコルの異なったカプセル化(protocolDirTableに異なったエントリーで表される)に割り当てられるのは、可能です。
Bierman & Iddon Standards Track [Page 12] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[12ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
A protocol name should match the "most well-known" name or acronym for the indicated protocol. For example, the document indicated by the URL:
プロトコル名は示されたプロトコルのための「最もよく知られている」名前か頭文字語に合うべきです。 例えばURLによって示されたドキュメント:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for children of IP should be given names consistent with the protocol names found in this authoritative document.
IPの子供のためのプロトコル識別子マクロがこの信頼すべき文書で見つけられるプロトコル名と一致した名であるべきであり分野が評価するIPプロトコルを定義します。
4.2.2. Mapping of the VARIANT-OF Clause
4.2.2. マッピング、異形、-、節
This clause is present for IANA assigned protocols only. It identifies the protocol-identifier macro that most closely represents this particular protocol, and is known as the "reference protocol". (A protocol-identifier macro must exist for the reference protocol.) When this clause is present in a protocol-identifier macro, the macro is called a 'protocol-variant-identifier'.
この節はプロトコルだけが割り当てられたIANAのために存在しています。 それは、最も密接にこの特定のプロトコルを表すプロトコル識別子マクロを特定して、「参照プロトコル」として知られています。 (プロトコル識別子マクロは参照プロトコルのために存在しなければなりません。) この節がプロトコル識別子マクロで存在しているとき、マクロは'プロトコル異形識別子'と呼ばれます。
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol- identifier macro should not be duplicated in the protocol-variant- identifier macro, if the 'variant' protocols' semantics are identical for a given clause.
プロトコル識別子マクロがそうするべきである参照におけるどんな節(例えば、CHILDREN、ADDRESS-FORMAT)も異形識別子について議定書の中で述べているマクロでコピーされないで、与えられた節に、プロトコルの意味論は'異形'であるなら同じです。
Since the PARAMETERS and ATTRIBUTES clauses must be present in a
protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
"PARAMETERS {}") must be present in a protocol-variant-identifier
macro, and the 'ParamPart' and 'AttrPart' found in the reference
protocol- identifier macro examined instead.
PARAMETERSとATTRIBUTES節が以来にプロトコル識別子に存在していて空の'ParamPart'と'AttrPart'であるに違いない、(すなわち、「パラメタ」{}現在のコネがaであったに違いないなら異形識別子について議定書の中で述べてください。「)、''プロトコル識別子マクロが代わりに調べた参照では見つけられた」マクロ、'ParamPart'、およびAttrPart。
Note that if a 'ianaAssigned' protocol is defined that is not a variant of any other documented protocol, then the protocol- identifier macro should be used instead of the protocol-variant- identifier version of the macro.
いかなる他の記録されたプロトコルの異形でない'ianaAssigned'プロトコルも定義されるならプロトコル識別子マクロがマクロの異形識別子について議定書の中で述べているバージョンの代わりに使用されるべきであることに注意してください。
4.2.3. Mapping of the PARAMETERS Clause
4.2.3. パラメタ節に関するマッピング
The protocolDirParameters object provides an NMS the ability to turn on and off expensive probe resources. An agent may support a given parameter all the time, not at all, or subject to current resource load.
protocolDirParametersオブジェクトは断続的に高価な徹底的調査リソースをターンする能力をNMSに供給します。 エージェントは、全く、または現在のリソース負荷を条件として与えられたパラメタがすべて、時間であるとサポートするかもしれません。
The PARAMETERS clause is a list of bit definitions which can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions may be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conforming agent may choose to implement a subset of zero or more of these PARAMETERS.
PARAMETERS節は直接ネットワークバイトオーダーにおける関連ProtocolDirParameters八重奏にコード化できる噛み付いている定義のリストです。 ゼロかさらに噛み付いている定義が存在しているかもしれません。 ビット0-7だけが、値をコード化しながら、有効です。 この節は与えられたプロトコルのために許容された全体のBITセットを定義します。 従っているエージェントは、ゼロの部分集合かこれらのPARAMETERSの以上を実装するのを選ぶかもしれません。
Bierman & Iddon Standards Track [Page 13] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[13ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
By convention, the following common bit definitions are used by different protocols. These bit positions must not be used for other parameters. They should be reserved if not used by a given protocol. Bits are encoded in network-byte order.
コンベンションによって、以下の一般的な噛み付いている定義は異なったプロトコルによって使用されます。 他のパラメタにこれらのビット位置を使用してはいけません。 それらは、与えられたプロトコルによって予約されるべきであるか、または使用されるべきです。 ビットはネットワークバイトオーダーでコード化されます。
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
テーブル3.1はパラメタビットを予約しました。------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
噛み付いている名前記述--------------------------------------------------------------------- 0 このプロトコルが上側の層を複数のパケットに断片化しても、このプロトコルの中でカプセル化されたcountsFragments上位層プロトコルは正しく数えられるでしょう。 1 tracksSessionsは正しくよく知られているポートかソケットにセッションを始めて、次にその後ダイナミックに割り当てられたポートかソケットにそれらを移すプロトコル(例えば、TFTP)のすべてのパケットを結果と考えます。
The PARAMETERS clause must be present in all protocol-identifier macro declarations, but may be equal to zero (empty). Note that an NMS must determine if a given PARAMETER bit is supported by attempting to create the desired protocolDirEntry The associated ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not exist.
PARAMETERS節は、すべてのプロトコル識別子マクロ宣言で存在していなければなりませんが、ゼロに合わせるために等しいかもしれません(空の)。 NMSが、必要なprotocolDirEntryを作成するのを試みることによって与えられたPARAMETERビットが支えられるなら'countsFragments'と'tracksSessions'のための関連ATTRIBUTEビットが存在しないことを決定しなければならないことに注意してください。
4.2.3.1. Mapping of the 'countsFragments(0)' BIT
4.2.3.1. 'countsFragments(0)'ビットのマッピング
This bit indicates whether the probe is correctly attributing all fragmented packets of the specified protocol, even if individual frames carrying this protocol cannot be identified as such. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS.
このビットは、徹底的調査が正しくすべてを結果と考えているかどうかが指定されたプロトコルのパケットを断片化したのを示します、そういうものとしてこのプロトコルを運ぶ個々のフレームを特定できないでも。 徹底的調査は実際に、どんな組み立て直されたデータグラム(アドレス分析、フィルタリング、またはいかなる他の目的のためのも)もNMSに贈るのに必要でないことに注意してください。
This bit may only be set in a protocolDirParameters octet which corresponds to a protocol that supports fragmentation and reassembly in some form. Note that TCP packets are not considered 'fragmented- streams' and so TCP is not eligible.
このビットは、断片化をサポートするプロトコルに対応するprotocolDirParameters八重奏で設定されるだけであり、何らかのフォームで再アセンブリされるかもしれません。 TCPパケットが考えられないというメモが'ストリームを断片化した'ので、TCPは適任ではありません。
This bit may be set in at most one protocolDirParameters octet within a protocolDirTable INDEX.
このビットは高々protocolDirTable INDEXの中の1つのprotocolDirParameters八重奏で設定されるかもしれません。
Bierman & Iddon Standards Track [Page 14] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[14ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
4.2.3.2. Mapping of the 'tracksSessions(1)' BIT
4.2.3.2. 'tracksSessions(1)'ビットのマッピング
The 'tracksSessions(1)' bit indicates whether frames which are part of remapped-sessions (e.g. TFTP download sessions) are correctly counted by the probe. For such a protocol, the probe must usually analyze all packets received on the indicated interface, and maintain some state information, (e.g. the remapped UDP port number for TFTP).
'tracksSessions(1)'ビットは、再写像しているセッション(例えば、TFTPダウンロードセッション)の一部であるフレームが徹底的調査で正しく数えられるかどうかを示します。 そのようなプロトコルのために、探測装置は、通常、示されたインタフェースに受け取られたすべてのパケットを分析して、何らかの州の情報(例えば、TFTPのためのremapped UDPポートナンバー)を保守しなければなりません。
The semantics of the 'tracksSessions' parameter are independent of the other protocolDirParameters definitions, so this parameter may be combined with any other legal parameter configurations.
'tracksSessions'パラメタの意味論が他のprotocolDirParameters定義から独立しているので、このパラメタはいかなる他の法的なパラメタ構成にも結合されるかもしれません。
4.2.4. Mapping of the ATTRIBUTES Clause
4.2.4. 属性節に関するマッピング
The protocolDirType object provides an NMS with an indication of a probe's capabilities for decoding a given protocol, or the general attributes of the particular protocol.
protocolDirTypeオブジェクトは与えられたプロトコルを解読するための徹底的調査の能力のしるし、または特定のプロトコルの一般属性をNMSに提供します。
The ATTRIBUTES clause is a list of bit definitions which are encoded into the associated instance of ProtocolDirType. The BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object.
ATTRIBUTES節はProtocolDirTypeの関連インスタンスにコード化される噛み付いている定義のリストです。 BIT定義はprotocolDirType MIBオブジェクトのSYNTAX節で指定されます。
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
テーブル3.2は属性ビットを予約しました。------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
噛み付いている名前記述--------------------------------------------------------------------- 0 hasChildrenは、protocolDirTable(エージェントかマネージャのどちらかによる)で定義されたこのプロトコルの子供がいるかもしれないのを示します。 1 addressRecognitionCapableは、ホストとマトリクスがテーブル項目であると生成するのにこのプロトコルを使用できるのを示します。
The ATTRIBUTES clause must be present in all protocol-identifier macro declarations, but may be empty.
ATTRIBUTES節は、すべてのプロトコル識別子マクロ宣言で存在していなければなりませんが、空であるかもしれません。
4.2.5. Mapping of the DESCRIPTION Clause
4.2.5. 記述節に関するマッピング
The DESCRIPTION clause provides a textual description of the protocol identified by this macro. Notice that it should not contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses.
記述節はこのマクロによって特定されたプロトコルの原文の記述を提供します。 それがCHILDREN、ADDRESS-FORMAT、DECODING、およびREFERENCE節でカバーされた項目に関する詳細を含むべきでないのに注意してください。
The DESCRIPTION clause must be present in all protocol-identifier macro declarations.
記述節はすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
Bierman & Iddon Standards Track [Page 15] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[15ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
4.2.6. Mapping of the CHILDREN Clause
4.2.6. 子供節に関するマッピング
The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections:
CHILDREN節は子供プロトコルの記述をそれらをサポートするプロトコルに提供します。 それには、3つの小区分があります:
- Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed
- 分野/値に関する詳細は以前はよく子供プロトコルと、その選択プロセスがどう実行されるかを選択していました。
- Details on how the value(s) are encoded in the protocol identifier
octet string
- 値がプロトコル識別子八重奏ストリングでどうコード化されるかに関する詳細
- Details on how child protocols are named with respect to their
parent protocol label(s)
- 子供プロトコルがそれらの親プロトコルラベルに関してどう命名されるかに関する詳細(s)
The CHILDREN clause must be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause.
CHILDREN節は'hasChildren(0)'BITがATTRIBUTES節で用意ができているすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
4.2.7. Mapping of the ADDRESS-FORMAT Clause
4.2.7. アドレス形式節に関するマッピング
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses.
ADDRESS-FORMAT節はアドレスをコード化するとき使用されるOCTET-STRING形式の記述を提供します。
This clause must be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause.
この節は'addressRecognitionCapable(1)'BITがATTRIBUTES節で用意ができているすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
4.2.8. Mapping of the DECODING Clause
4.2.8. 解読節に関するマッピング
The DECODING clause provides a description of the decoding procedure for the specified protocol. It contains useful decoding hints for the implementor, but should not over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required.
DECODING節は解読手順の記述を指定されたプロトコルに提供します。 それは、作成者のために役に立つ解読ヒントを含んでいますが、REFERENCE節で引用されたドキュメントで情報を模写し過ぎるべきではありません。 それは情報が必要とした解読の完全な記述を含むかもしれません。
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection
as well as information on determining the start of the child
protocol.
これが含む'広げることができる'プロトコル('hasChildren(0)'BITはセットした)のために、子供プロトコルの始まりを決定することの情報と同様に子供選択に使用される分野のための情報を相殺して、タイプしてください。
For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses.
これが含む'addressRecognitionCapable'プロトコルには、アドレスを作るのに使用される分野のための情報を相殺して、タイプしてください。
The DECODING clause is optional, and may be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol.
DECODING節は、任意であり、REFERENCE節が指定されたプロトコルのための情報を解読するのに指針を含んでいるなら、省略されるかもしれません。
Bierman & Iddon Standards Track [Page 16] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[16ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
4.2.9. Mapping of the REFERENCE Clause
4.2.9. 参照節に関するマッピング
If a publicly available reference document exists for this protocol it should be listed here. Typically this will be a URL if possible; if not then it will be the name and address of the controlling body.
公的に利用可能な参考書類がこのプロトコルのために存在しているなら、それはここに記載されるべきです。 できれば、これは通常、URLになるでしょう。 まして、そして、それは、制御ボディーの名前とアドレスになるでしょう。
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the amount of information which may currently be obtained from an 'authoritative' document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document.
CHILDREN、ADDRESS-FORMAT、およびDECODING節は現在'正式'のドキュメントから得られるかもしれない情報量を制限するべきです、Assigned民数記ドキュメント[RFC1700]などのように。 情報のどんな複製か言い換えも、信頼すべき文書と簡潔であって、一致しているべきです。
The REFERENCE clause is optional, but should be implemented if an authoritative reference exists for the protocol (especially for standard protocols).
REFERENCE節は、任意ですが、正式の参照がプロトコル(特に標準プロトコルのための)のために存在しているなら、実装されるべきです。
4.2.10. Evaluating a Protocol-Identifier INDEX
4.2.10. プロトコル識別子インデックスを評価します。
The following evaluation is done after protocolDirTable INDEX value has been converted into two OCTET STRINGs according to the INDEX encoding rules specified in the SMI [RFC1902].
SMI[RFC1902]で指定されたINDEX符号化規則によると、protocolDirTable INDEX値を2OCTET STRINGsに変換した後に以下の評価をします。
Protocol-identifiers are evaluated left to right, starting with the protocolDirID, which length should be evenly divisible by four. The protocolDirParameters length should be exactly one quarter of the protocolDirID string length.
4で分割可能な状態でprotocolDirID(長さは均等にそうであるべきである)から始まって、プロトコル識別子は左で右に評価されます。 protocolDirParametersの長さはまさにprotocolDirIDストリング長の四分の一であるべきです。
Protocol-identifier parsing starts with the base layer identifier, which must be present, and continues for one or more upper layer identifiers, until all OCTETs of the protocolDirID have been used. Layers may not be skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can not exist.
プロトコル識別子構文解析は、存在しなければならない基層識別子から始まって、1つ以上の上側の層の識別子のために続きます、protocolDirIDのすべてのOCTETsが使用されるまで。 層がスキップされないかもしれないので、'IPの上のSNMP'か'anylinkの上のTCP'などの識別子は存在できません。
The base-layer-identifier also contains a 'special function identifier' which may apply to the rest of the protocol identifier.
また、ベース層の識別子はプロトコル識別子の残りに適用されるかもしれない'特別な機能識別子'を含んでいます。
Wild-carding at the base layer within a protocol encapsulation is the only supported special function at this time. Refer to the 'Base Protocol Identifiers' section for wildcard encoding rules.
このとき、プロトコルカプセル化の中の基層のワイルドな梳綿機は唯一のサポートしている特別な機能です。 ワイルドカード符号化規則について'基地のプロトコルIdentifiers'セクションを参照してください。
After the protocol-tree identified in protocolDirID has been parsed, each parameter bit-mask (one octet for each 4-octet layer-identifier) is evaluated, and applied to the corresponding protocol layer.
protocolDirIDで特定されたプロトコル木が分析された後に、それぞれのパラメタビットマスク(それぞれの4八重奏の層識別子あたり1つの八重奏)は、対応するプロトコル層に評価されて、適用されます。
A protocol-identifier label may map to more than one value. For instance, 'ip' maps to 5 distinct values, one for each supported encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'),
プロトコル識別子ラベルは値を1つ以上に写像するかもしれません。 例えば、'ip'は異なった値、カプセル化であるとサポートされたそれぞれのためのものを5に写像します。 ('L3プロトコルIdentifiers'の下の'IP'セクションを見ます),
Bierman & Iddon Standards Track [Page 17] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[17ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
It is important to note that these macros are conceptually expanded at implementation time, not at run time.
これらのマクロがランタイムのときに広げられるのではなく、実行時間に概念的に広げられることに注意するのは重要です。
If all the macros are expanded completely by substituting all possible values of each label for each child protocol, a list of all possible protocol-identifiers is produced. So 'ip' would result in 5 distinct protocol-identifiers. Likewise each child of 'ip' would map to at least 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, ip over LLC, etc.).
すべてのマクロが完全にそれぞれのラベルのすべての可能な値をそれぞれの子供プロトコルの代わりに用いることによって広げられるなら、すべての可能なプロトコル識別子のリストは作り出されます。 それで、'ip'は5つの異なったプロトコル識別子をもたらすでしょう。 'ip'の同様に各子供はプロトコル識別子(各カプセル化(例えば、ether2の上のip、LLCの上のipなど)あたり1つ)を少なくとも5に写像するでしょう。
5. Protocol Identifier Macros
5. プロトコル識別子マクロ
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings.
protocolDirIDとprotocolDirParametersストリングを構成するのに以下のPROTOCOL IDENTIFIERマクロを使用できます。
The sections defining protocol examples are intended to grow over subsequent releases. Minimal protocol support is included at this time. (Refer to section 3.2 for details on the protocol macro update procedure.)
プロトコルの例を定義するセクションがその後のリリースを覆うことを意図します。 最小量のプロトコルサポートはこのとき、含まれています。 (プロトコルマクロアップデート手順に関する詳細についてセクション3.2を参照してください。)
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol.
識別子は、1つの層識別子がその時それぞれのカプセル化されたプロトコルのために加えて、ベース識別子を構成することによって、コード化されます。
5.1. Base Identifier Encoding
5.1. 基地の識別子コード化
The first layer encapsulation is called the base identifier and it contains optional protocol-function information and the base layer (e.g. MAC layer) enumeration value used in this protocol identifier.
初層カプセル化はベース識別子と呼ばれます、そして、それはこのプロトコル識別子で使用される任意のプロトコル機能情報と基層(例えば、MACは層にする)列挙価値を含んでいます。
The base identifier is encoded as four octets as shown in figure 2.
ベース識別子は示されるとしての4つの八重奏としてコード化されて、2が中で計算するということです。
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
図2 ベース識別子形式+---+---+---+---+ | | | | | | f|op1|op2| m| | | | | | +---+---+---+---+ 八重奏| 1 | 1 | 1 | 1 | カウント
The first octet ('f') is the special function code, found in table
4.1. The next two octets ('op1' and 'op2') are operands for the
indicated function. If not used, an operand must be set to zero. The
last octet, 'm', is the enumerated value for a particular base layer
encapsulation, found in table 4.2. All four octets are encoded in
network-byte-order.
最初の八重奏('f')はテーブル4.1で見つけられた特別な機能コードです。 次の2つの八重奏('op1'と'op2')が示された機能のためのオペランドです。 使用されないなら、ゼロにオペランドを設定しなければなりません。 '最後の八重奏、'列挙された値はテーブル4.2で見つけられた特定の基層カプセル化のためのものです。 すべての4つの八重奏がネットワークバイトオーダーでコード化されます。
Bierman & Iddon Standards Track [Page 18] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[18ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.1.1. Protocol Identifier Functions
5.1.1. プロトコル識別子機能
The base layer identifier contains information about any special functions to perform during collections of this protocol, as well as the base layer encapsulation identifier.
基層識別子はこのプロトコルの収集の間に実行するどんな特別な機能の情報も含んでいます、基層カプセル化識別子と同様に。
The first three octets of the identifier contain the function code and two optional operands. The fourth octet contains the particular base layer encapsulation used in this protocol (fig. 2).
識別子の最初の3つの八重奏が機能コードと2つの任意のオペランドを含んでいます。 4番目の八重奏はこのプロトコル(図2)に使用される特定の基層カプセル化を含んでいます。
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
プロトコル識別子機能が割り当てられたテーブル4.1-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
機能ID Param1 Param2---------------------------------------------------- (0) 使用されないで、中古の(0)ワイルドカード1ではなく、0の中古でない(0)が使用しなかったなし(0)
5.1.1.1. Function 0: No-op
5.1.1.1. 機�%%BODY%%: オプアートがありません。
If the function ID field (1st octet) is equal to zero, the the 'op1' and 'op2' fields (2nd and 3rd octets) must also be equal to zero. This special value indicates that no functions are applied to the protocol identifier encoded in the remaining octets. The identifier represents a normal protocol encapsulation.
また、機能ID分野(最初の八重奏)がゼロに合わせるために等しいなら、'op1'と'op2'分野(2番目と3番目の八重奏)も、ゼロに合わせるために等しくなければなりません。 この特別な値は、機能が全く残っている八重奏でコード化されたプロトコル識別子に適用されないのを示します。 識別子は正常なプロトコルカプセル化を表します。
5.1.1.2. Function 1: Protocol Wildcard Function
5.1.1.2. 機能1: プロトコルワイルドカード機能
The wildcard function (function-ID = 1), is used to aggregate counters, by using a single protocol value to indicate potentially many base layer encapsulations of a particular network layer protocol. A protocolDirEntry of this type will match any base-layer encapsulation of the same protocol.
ワイルドカード機能(機能ID=1)は特定のネットワーク層プロトコルの潜在的に多くの基層カプセル化を示すのにただ一つのプロトコル値を使用することによってカウンタに集めるのにおいて使用されています。 このタイプのprotocolDirEntryは同じプロトコルのどんな基層カプセル化にも合うでしょう。
The 'op1' field (2nd octet) is not used and must be set to zero.
'op1'分野(2番目の八重奏)を使用されていなくて、ゼロに設定しなければなりません。
The 'op2' field (3rd octet) is not used and must be set to zero.
'op2'分野(3番目の八重奏)を使用されていなくて、ゼロに設定しなければなりません。
Each wildcard protocol identifier must be defined in terms of a 'base encapsulation'. This should be as 'standard' as possible for interoperability purposes. If an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation.
'ベースカプセル化'でそれぞれのワイルドカードプロトコル識別子を定義しなければなりません。 これは相互運用性目的のためにできるだけ'標準であるべきです'。 'ether2'の上のカプセル化がこれがベースカプセル化として使用されるべきであるより受入れられるなら。
Bierman & Iddon Standards Track [Page 19] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[19ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
The agent may also be requested to count some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RMON2] does not require that agents maintain counters for multiple encapsulations of the same protocol. It is an implementation-specific matter as to how an agent determines which protocol combinations to allow in the protocolDirTable at any given time.
また、エージェントが同じプロトコルのために個々のカプセル化のいくつかかすべてを数えるよう要求されているかもしれません、ワイルドカード勘定に加えて。 RMON-2 MIB[RMON2]が、エージェントが同じプロトコルの複数のカプセル化のためにカウンタを維持するのを必要としないことに注意してください。 それはエージェントが、その時々でprotocolDirTableでどのプロトコル組み合わせを許すかをどう決心するかに関する実装特有の問題です。
5.2. Base Layer Protocol Identifiers
5.2. 基層プロトコル識別子
The base layer is mandatory, and defines the base encapsulation of the packet and any special functions for this identifier.
基層は、義務的であり、この識別子のためにパケットのベースカプセル化とどんな特別な機能も定義します。
There are no suggested protocolDirParameters bits for the base layer.
基層のためのprotocolDirParametersビットは示されません。
The suggested ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in the table 4.1 below. However, implementations are only required to use the appropriate integer identifier values.
テーブル4.1の分野という対応する「名前」は基層のための提案されたProtocolDirDescr野原を以下に与えます。 しかしながら、実装が、適切な整数識別子値を使用するのに必要であるだけです。
For most base layer protocols, the protocolDirType field should contain bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)' attributes. However, the special 'ianaAssigned' base layer should have no parameter or attribute bits set.
ほとんどの基層プロトコルのために、protocolDirType分野は'hasChildren(0)'と'addressRecognitionCapable(1)'属性に設定されたビットを含むべきです。 しかしながら、特別な'ianaAssigned'基層で、どんなパラメタも属性ビットも設定するはずがありません。
By design, only 255 different base layer encapsulations are supported. There are five base encapsulation values defined at this time. New base encapsulations (e.g. for new media types) are expected to be added over time.
故意に、255の異なった基層カプセル化だけがサポートされます。 このとき定義されている5つのベースカプセル化値があります。 時間がたつにつれて新しいベースカプセル化(例えば、ニューメディアタイプのための)が加えられると予想されます。
Table 4.2 Base Layer Encoding Values
--------------------------------------
テーブル4.2 値をコード化する基層--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
名前ID------------------ ether2 1 llc2は3vsnap4ianaAssigned5を折ります。
Bierman & Iddon Standards Track [Page 20] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[20ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.2.1. Ether2 Encapsulation
5.2.1. Ether2カプセル化
ether2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
ether2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「また、イーサネットIIと呼ばれるDIXイーサネット。」 CHILDREN「タイプ分野が使用されているイーサネットIIの選んだ子供プロトコル。」 これは16ビットの分野です。 子供プロトコルがこのタイプ分野の後の最初の八重奏のときに出発すると考えられます。
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the MSB and
LSB of the Ethernet-II type value.
このプロトコルの子供がコード化される、[0.0 .0 .1] 'ether2'のためのプロトコル識別子は'a'と'b'がネットワークバイトオーダーのMSBのencodingsとイーサネットIIタイプ価値のLSBである[0.0.a.b]で従いました。
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.8.0、ether2でカプセル化されたIPを定義します。
Children of are named as 'ether2' followed by the type field
value in hexadecimal. The above example would be declared as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)."
REFERENCE
"A Standard for the Transmission of IP Datagrams over Ethernet
Networks; RFC 894 [RFC894].
子供、'ether2'が16進のタイプ分野価値で続いたので、命名されます。 上記の例は以下として宣言されるでしょう。 「ether2 0x0800」ADDRESS-FORMAT、「イーサネット・アドレスはネットワークオーダーで6つの八重奏です」。 DECODINGは「1500以上小数が、イーサネットIIが縁どるのを示す値をタイプするだけです」。 「下側の値は802.3に、カプセル化(以下を見る)を示します。」 「イーサネットネットワークの上のIPデータグラムの送信の規格」という参照。 RFC894[RFC894]。
The authoritative list of Ether Type values is identified by the
URL:
Ether Type値の正式のリストはURLによって特定されます:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
" ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers ":、:= { 1 }
Bierman & Iddon Standards Track [Page 21] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[21ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.2.2. LLC Encapsulation
5.2.2. LLCカプセル化
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The LLC (802.2) protocol."
CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) are
used to select child protocols. Each of these is one octet long,
although the least significant bit is a control bit and should be
masked out in most situations. Typically SSAP and DSAP (once
masked) are the same for a given protocol - each end implicitly
knows whether it is the server or client in a client/server
protocol. This is only a convention, however, and it is possible
for them to be different. The SSAP is matched against child
protocols first. If none is found then the DSAP is matched
instead. The child protocol is deemed to start at the first
octet after the LLC control field(s).
llcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、「LLC(802.2)は議定書の中で述べる」記述。 CHILDREN、「LLC SSAPとDSAP(ソース/Dest Service Access Points)は子供プロトコルを選択するのに使用されます」。 長い間、それぞれのこれらは1つの八重奏です、最下位ビットが、コントロールビットであり、ほとんどの状況で覆い隠されるべきですが。 与えられたプロトコルに、SSAPとDSAP(かつての仮面の)は通常、同じです--各端は、それがクライアント/サーバプロトコルでサーバかそれともクライアントであるかをそれとなく知っています。 しかしながら、これはコンベンションにすぎません、そして、それらが異なるのは、可能です。 SSAPは最初に、子供プロトコルに取り組まされます。 なにも見つけられないなら、DSAPは代わりに合わせられています。 LLCが分野を制御した後に子供プロトコルが最初の八重奏のときに出発すると考えられます。
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
'llc'の子供がコード化される、[0.0 .0 .2] LLCのためのプロトコル識別子コンポーネントは[0.0.0.a]で'a'が子供への地図が議定書の中で述べるSAP値であるところに続きました。 例えば、以下のprotocolDirID-断片値 0.0.0.2.0.0.0.240
defines NetBios over LLC.
LLCの上でNetBiosを定義します。
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
'llc'が16進のSAP値で続いたので、子供は命名されます。 それで、上記の例は命名されたでしょう: llc 0xf0" ADDRESS-FORMAT、「アドレスはネットワークオーダーにおける、MACアドレスの6つの八重奏から成ります」。 「存在しているなら、アドレスからソースルーティングビットを剥取るべきです。」 DECODINGは「LLCには可変長プロトコルヘッダーがあるのに気付きます」。 3つの八重奏がいつもあります(DSAP(SSAP)は制御します)。 そこでDSAP、SSAP、および制御フィールドのコントロールビットの価値に依存するのは、制御情報の追加八重奏であるかもしれません。
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw802.3
encapsulations). For 802.5 there is no other link layer
protocol.
LLCはいくつかの異なったメディアに存在している場合があります。 802.3と802.5において、存在は強制されます(ether2とraw802.3カプセル化を見てください)。 802.5のために、他のリンクレイヤプロトコルは全くありません。
Bierman & Iddon Standards Track [Page 22] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[22ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
「また、また、raw802.3も存在しているならraw802.3リンクレイヤプロトコルがすべてのLSAP値を利用するのが可能でないようにこれの上でプロトコルの特定の方法で優先するかもしれないのに注意してください。」 REFERENCE、「LLC LSAP値の正式のリストはIEEE Registration Authorityによって制御されます」。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 2 }
5.2.3. SNAP over LLC (OUI=000) Encapsulation
5.2.3. LLC(OUI=000)カプセル化の上で折ってください。
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP PID (Protocol Identifier) field is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
プロトコル-IDENTIFIER PARAMETERSを折ってください、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、「LLCに制限されたメディアの上に実行されて、Sub-ネットワークAccessプロトコル(SNAP)はイーサネットIIプロトコルを許容するLLCプロトコルの上で層にされる」記述。 CHILDREN、「'スナップ'の子供はイーサネットIIタイプ値によって特定されます」。 SNAP PID(プロトコルIdentifier)分野は、適切な子供を選ぶのに使用されます。 全体のSNAPプロトコルヘッダーは疲れています。 子供プロトコルがPIDの後の次の八重奏のときに始まると思われます。
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
are the MSB and LSB of the Ethernet-II type value. For example,
a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
'スナップ'の子供がコード化される、[0.0 .0 .3('スナップ'のためのプロトコル識別子)は]'a'と'b'がイーサネットIIタイプ価値のMSBとLSBである[0.0.a.b]で続きました。 例えば、以下のprotocolDirID-断片値 0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
IP/SNAPプロトコルを定義します。
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
このプロトコルの子供は16進のイーサネットIIタイプ価値があとに続いた'スナップ'と命名されます。 上記の例は命名されるでしょう:
snap 0x0800"
「0×0800を折ってください」
Bierman & Iddon Standards Track [Page 23] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[23ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of OUI and two octets of PID. For this encapsulation the
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
」 LLCのためのそれと同じくらいはDECODINGです。ADDRESS-FORMAT、「SNAPのためのアドレス形式、「SNAPはLLCの上に存在しているだけです」。 SSAPとDSAPの両方が0xAAになるでしょう、そして、単一管理八重奏は存在するでしょう。 その時、OUIの3つの八重奏とPIDの2つの八重奏があります。 「このカプセル化のために、OUIは0×000000でなければなりません(非ゼロOUIsに関して以下の'vsnap'を見てください)。」 REFERENCEは「IEEE Standardsオフィスによって割り当てSNAP Identifierが評価するされます」。 アドレスは以下の通りです。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 3 }
5.2.4. SNAP over LLC (OUI != 000) Encapsulation
5.2.4. LLC(OUI!=000)カプセル化の上で折ってください。
vsnap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that do."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet.
vsnapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「この疑似プロトコルはOUIを全く持っていないすべてのSNAPパケットを扱います」。 「そうするそれらの詳細において、'スナップ'が上であることを見てください。」 CHILDREN、「'vsnap'の子供は3八重奏OUIによって選ばれます」。 PIDは分析されません。 子供プロトコルは、まず第一にSNAP PID分野の最初の八重奏であると考えられて、パケットの端まで続きます。
Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order. This is in turn followed by the 16-bit EtherType
value, where the 'd' and 'e' represent the MSB and LSB of the
EtherType, respectively.
'vsnap'の子供がコード化される、[0.0 .0 .4('vsnap'のためのプロトコル識別子)は][0.a.b.c.0.0.d.e]で'a'、'b'、および'c'がネットワークバイトオーダーで、OUI分野の3つの八重奏であるところに続きました。 '16ビットのEtherType値は順番にこれのあとに続いています、どこ、''e'はそれぞれEtherTypeのMSBとLSBを表すでしょうか?
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7.0.0.128.155
defines the AppleTalk Phase 2 protocol over vsnap.
例えば、以下のprotocolDirID-断片値 0.0.0.4.0.8.0.7.0.0.128.155、vsnapの上でAppleTalk Phase2プロトコルを定義します。
Bierman & Iddon Standards Track [Page 24] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[24ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
Note that two protocolDirParameters octets must be present in
protocolDirTable INDEX values for 'vsnap' protocols. The first
protocolDirParameters octet defines the actual parameters. The
second protocolDirParameters octet is not used and must be set to
zero.
2つのprotocolDirParameters八重奏が'vsnap'プロトコルのためにprotocolDirTable INDEX値で存在していなければならないことに注意してください。 最初のprotocolDirParameters八重奏は実引数を定義します。 2番目のprotocolDirParameters八重奏を使用されていなくて、ゼロに設定しなければなりません。
Children are named as 'vsnap(<OUI>) <ethertype>', where the
'<OUI>' field is represented as 3 octets in hexadecimal notation
or the ASCII string associated with the OUI value. The
<ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named:
'vsnap(<OUI>)<ethertype>'('<OUI>'分野は16進法における3つの八重奏かASCIIストリングとして表される)がOUI値と交際したので、子供は命名されます。 <ethertype>分野は16進法における2バイトのEtherType値によって表されます。 それで、上記の例は命名されるでしょう:
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
「'vsnap(0×080007)0x809b''vsnap(りんご)0x809b'」ADDRESS-FORMAT「LLCアドレス形式で、世襲される'vsnap'。」 「その他の詳細のための'llc'プロトコル識別子を見てください。」 「'OUIが'スナップのための非ゼロであるのと同じ」DECODING。 REFERENCEは「IEEE Standardsオフィスによって割り当てSNAP Identifierが評価するされます」。 アドレスは以下の通りです。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 4 }
5.2.5. IANA Assigned Protocols
5.2.5. プロトコルが割り当てられたIANA
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic. preventing the any 'well-known'
protocol-identifier macro from being used.
プロトコル-IDENTIFIER PARAMETERSをianaAssignedした、ATTRIBUTES、記述、「このブランチは容易に他のリンクレイヤブランチで利用された階層的な形式に従わないプロトコルを含んでいます」。 通常、そのようなプロトコルが特定の'よく知られる'識別子形式に'ほとんど'従いますが、追加評価基準が使用されている、(例えば、構成ベース、)、適切なネットワークトラフィック防止の試験でプロトコル識別を難しいか不可能にする、使用されるのからのどんな'よく知られる'プロトコル識別子マクロ。
Bierman & Iddon Standards Track [Page 25] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[25ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'user-extensibility' feature of the
protocolDirTable, and do not need special IANA
assignments.
時々よく知られるプロトコルは1人以上のベンダー(例えば、SNMP)によって単に異なったポートナンバーに再写像されます。 これらのプロトコルは、protocolDirTableの'ユーザ伸展性'の特徴と同一視できて、特別なIANA課題を必要としません。
A centrally located list of these enumerated protocols must be
maintained to insure interoperability.
(See section 3.2 for details on the document update procedure.)
Support for new link-layers will be added explicitly, and only
protocols which cannot possibly be represented in a better way
will be considered as 'ianaEnumerated' protocols.
相互運用性を保障するためにこれらの列挙されたプロトコルの中心に位置しているリストを維持しなければなりません。 (ドキュメントアップデート手順に関する詳細に関してセクション3.2を見てください。) 新しいリンクレイヤのサポートは明らかに言い足されるでしょう、そして、より良い方法で表すことができないプロトコルだけが'ianaEnumerated'プロトコルであるとみなされるでしょう。
IANA assigned protocols are identified by the base-layer-selector
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the
integer value corresponding to the particular IANA protocol.
プロトコルが割り当てられたIANAがベース層のセレクタ値によって特定される、[0.0 .0 .5] 特定のIANAプロトコルに対応する整数価値の4つの八重奏[a.b.c.d]があとに続いています。
Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers
above."
CHILDREN
"Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING'
clause within the protocol-variant-identifier macro for each
enumerated protocol.
「上の、より従来のリンクレイヤで彼らを扱うことができないのを確信していない場合、このプロトコルの子供を創造しないでください。」 CHILDREN、「このプロトコルの子供はそれぞれの列挙されたプロトコルのためにプロトコル異形識別子マクロの中で'DECODING'節で説明された(できるだけ最も良い)実装の特定の手段で特定されます」。
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
例えば、以下のprotocolDirID-断片値 0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
直接802.3でカプセル化されたIPXプロトコルを定義します。
Children are named 'ianaAssigned' followed by the name or numeric
of the particular IANA assigned protocol. The above
example would be named:
子供は特定のプロトコルが割り当てられたIANAの名前か数値があとに続いた'ianaAssigned'と命名されます。 上記の例は命名されるでしょう:
'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
「''1か'ianaAssigned ipxOverRaw8023をianaAssignedしました'」
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
DECODING、「'ianaAssigned'基層は、疑似プロトコルであり、解読されません」。 REFERENCEは「プロトコルが割り当てられたIANAのそれぞれの子供の情報について個々のプロトコル-IDENTIFIERマクロについて言及します」。 ::= { 5 }
Bierman & Iddon Standards Track [Page 26] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[26ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.2.5.1. IANA Assigned Protocol Identifiers
5.2.5.1. プロトコル識別子が割り当てられたIANA
The following protocol-variant-identifier macro declarations are used to identify the RMONMIB IANA assigned protocols in a proprietary way, by simple enumeration. Note that an additional four-octet layer identifier may be used for some enumerations (as with the 'vsnap' base-layer identifier). Refer to the 'CHILDREN' clause in the protocol-identifier macro for a particular protocol to determine the number of octets in the 'ianaAssigned' layer-identifier.
以下のプロトコル異形識別子マクロ宣言はプロトコルが独占方法で割り当てられたRMONMIB IANAを特定するのに使用されます、単純枚挙法で。 追加4八重奏の層の識別子がいくつかの列挙に使用されるかもしれないことに注意してください('vsnap'基層識別子のように)。 プロトコル識別子マクロにおける'CHILDREN'節を参照して、特定のプロトコルは'ianaAssigned'層識別子の八重奏の数を測定してください。
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF "ipx"
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
ipxOverRaw8023プロトコル-IDENTIFIER VARIANT-OF"ipx"PARAMETERS、ATTRIBUTES、記述、「この疑似プロトコルはIPXより多くの802.3のカプセル化について説明します、タイプ分野なしで」。
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= { ianaAssigned 1 }
「このプロトコルに関する追加情報のためにIPXについてマクロを参照してください。」 DECODING、「802.3ヘッダーがLLCを示すときはいつも、プロトコル特有のセットはこれが'raw8023'パケットかそれとも本当の802.2パケットであるかを決定するために適用されるべき必要性をテストします」。 「これらのテストの本質は、'raw8023'のためにアクティブな子供プロトコルによって、このドキュメントの範囲を超えています。」 ::= 1をianaAssignedしました。
5.3. L3: Children of Base Protocol Identifiers
5.3. L3: 基地のプロトコル識別子の子供
Network layer protocol identifier macros contain additional information about the network layer, and is found immediately following a base layer-identifier in a protocol identifier.
ネットワーク層プロトコル識別子マクロは、ネットワーク層に関する追加情報を含んでいて、すぐにプロトコル識別子のベース層識別子に従うのが見つけられます。
The ProtocolDirParameters supported at the network layer are 'countsFragments(0)', and 'tracksSessions(1). An agent may choose to implement a subset of these parameters.
ネットワーク層でサポートされたProtocolDirParametersは'countsFragments(0)'と、'tracksSessions(1)'です。 エージェントは、これらのパラメタの部分集合を実装するのを選ぶかもしれません。
The protocol-name should be used for the ProtocolDirDescr field. The ProtocolDirType ATTRIBUTES used at the network layer are 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose to implement a subset of these attributes for each protocol, and therefore limit which tables the indicated protocol can be present (e.g. protocol distribution, host, and matrix tables)..
プロトコル名はProtocolDirDescr分野に使用されるべきです。 ネットワーク層に使用されるProtocolDirType ATTRIBUTESは'hasChildren(0)'と'addressRecognitionCapable(1)'です。 エージェントは、各プロトコルのためにこれらの属性の部分集合を実装するのを選ぶかもしれません、そして、したがって、示されたプロトコルを見送る限界は存在している場合があります(例えば、プロトコル分配、ホスト、およびマトリクステーブル)。
The following protocol-identifier macro declarations are given for example purposes only. They are not intended to constitute an exhaustive list or an authoritative source for any of the protocol
以下のプロトコル識別子マクロ宣言に例えば目的だけを与えます。 彼らがプロトコルのどれかのために完全なりストか権威筋を構成することを意図しません。
Bierman & Iddon Standards Track [Page 27] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[27ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
information given. However, any protocol that can encapsulate other protocols must be documented here in order to encode the children identifiers into protocolDirID strings. Leaf protocols should be documented as well, but an implementation can identify a leaf protocol even if it isn't listed here (as long as the parent is documented).
与えられた情報。 しかしながら、子供識別子をprotocolDirIDストリングにコード化するためにここに他のプロトコルをカプセル化することができるどんなプロトコルも記録しなければなりません。 葉のプロトコルはまた、記録されるべきですが、それがここに記載されないでも(親が記録される限り)、実装は葉のプロトコルを特定できます。
5.3.1. IP
5.3.1. IP
ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0) -- This parameter applies to all child
-- protocols.
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of 'ip' are selected by the value in the Protocol field
(one octet), as defined in the PROTOCOL NUMBERS table within the
Assigned Numbers Document.
ipプロトコル-IDENTIFIER PARAMETERS、countsFragments(0)(パラメタがすべての子供に当てはまるこれ)プロトコル。 ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「インターネットプロトコル(IP)のためのプロトコル識別子。」 「以下の識別子の1つ以上が特定のprotocolDirIDストリングに存在させることができるように、IPがそれ自体の中でカプセル化されるかもしれないことに注意してください。」 CHILDREN、「'ip'の子供はプロトコル分野(1つの八重奏)の値によって選ばれます、Assigned民数記Documentの中のプロトコル民数記テーブルで定義されるように」。
The value of the Protocol field is encoded in an octet string as
[ 0.0.0.a ], where 'a' is the protocol field .
プロトコル分野の値は[0.0.0.a]として八重奏ストリングでコード化されます。そこでは、'a'がプロトコル分野です。
Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1
'ip'の子供は、'a'がプロトコル分野価値であるところで[0.0.0.a]としてコード化されて、'ip a'として命名されます。 例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2/ip/ipip4/udp is a different protocolDirID than
ether2/ip/udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
「ICMPのカプセル化を定義する、(ether2.ip.icmp) 」 「IPの4つの八重奏がネットワークバイトオーダーで扱う」ADDRESS-FORMAT。 「それぞれのipパケットは2つのアドレス、ソースアドレス、および送付先アドレスを含んでいます。」 「以下に注意してください」解読して、 ether2/ip/ipip4/udpはether2/ip/udp protocolDirTableで特定されるように異なったprotocolDirIDです。 そういうものとして、2つの異なった地方のプロトコルインデックス値がエージェントによって割り当てられるでしょう。 例えば (示された完全なINDEX値): 「ether2/ip/ipip4/udp16.0の.0.0.0.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4ether2/ip/udp12.0.0.0.1.0.0、.8、.0、.0、.0、.0、.17、.3、.0、.0、.0インチ
Bierman & Iddon Standards Track [Page 28] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[28ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
REFERENCE
"RFC 791 [RFC791] defines the Internet Protocol; The following
URL defines the authoritative repository for the PROTOCOL NUMBERS
Table:
REFERENCE、「RFC791[RFC791]はインターネットプロトコルを定義します」。 以下のURLはプロトコル民数記Tableのために正式の倉庫を定義します:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
ip 4,
ip 94
}
" ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers ":、:= ether2 0x0800(llc0x06)は0×0800、ip4、ip94を折ります。
5.3.2. IPX
5.3.2. IPX
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the
Destination Socket field. The value is encoded into an octet
string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
order encodings of the MSB and LSB of the destination socket
field."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"The IPX protocol is defined by the Novell Corporation
ipxプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「ノベルIPX」CHILDREN、「IPXの子供はDestination Socket分野の16ビットの値によって定義されます」。 「値は[0.0.a.b]として八重奏ストリングにコード化されます」。(そこでは、'a'と'b'は、ネットワークバイトオーダーのMSBのencodingsと目的地ソケット分野のLSBです)。 「4バイトのNetwork番号はそれぞれネットワークバイトオーダーにおける6バイトのHostアドレスで続いた」ADDRESS-FORMAT。 REFERENCE、「IPXプロトコルはノベル社によって定義されます」。
Bierman & Iddon Standards Track [Page 29] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[29ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}
以下のアドレスでIPXの完全な記述を保証するかもしれません: ノベルInc.122の東1700南部では、私書箱5900プロボ、ユタ84601米国800 526 5463ノベルは以下を#883-0007801インチ分けます:= ether2 0×8137--0.0.129.55llc 0xe0e003--0.224の.3の即座の0×8137--0.0.129.55.224ianaAssigned0x1--0.0.0.1(ipxOverRaw8023)
5.3.3. ARP
5.3.3. アルプ
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC 826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
arpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「Address Resolutionプロトコルは通信(要求か応答)にさせる」記述。 「このプロトコルはReverseアルプ(RARP)パケットを含んでいません」。(パケットは別々に数えられます)。 REFERENCE、「RFC826[RFC826]はAddress Resolutionプロトコルを定義します」。 ::= ether2 0x806--、[0.0.8.6]スナップ、0×806
5.3.4. IDP
5.3.4. IDP
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order."
idpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「ゼロックスIDP」CHILDREN、「IDPの子供はPacketタイプ分野の8ビットの値によって定義されます」。 「値は[0.0.0.a]として八重奏ストリングにコード化されます」。(そこでは、'a'がネットワークバイトオーダーで、パケットタイプ分野の値です)。
Bierman & Iddon Standards Track [Page 30] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[30ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}
「4バイトのNetwork番号はそれぞれネットワークバイトオーダーにおける6バイトのHostアドレスで続いた」ADDRESS-FORMAT。 「ゼロックス社、ドキュメントXNSS028112、1981」という参照:、:= ether2 0x600--、[0.0.6.0]スナップ、0×600
5.3.5. AppleTalk ARP
5.3.5. AppleTalk ARP
atalkarp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}
atalkarpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkアドレス解決プロトコル。」 REFERENCE、「AppleTalk Phase2プロトコルSpecification、ドキュメントADPA#C0144LL/A.」 ::= ether2 0x80f3--、[0.0.128.243]vsnap(0×080007)0x80f3
5.3.6. AppleTalk
5.3.6. AppleTalk
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network byte
order."
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order".
atalkプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「AppleTalkプロトコル。」 CHILDREN、「ATALKの子供はDDPタイプ分野の8ビットの値によって定義されます」。 「値は[0.0.0.a]として八重奏ストリングにコード化されます」。(そこでは、'a'がネットワークバイトオーダーで、DDPタイプ分野の値です)。 「数が続いたNetworkの2バイト×それぞれネットワークバイトオーダーにおける、ノードイドの1バイト」のADDRESS-FORMAT。
Bierman & Iddon Standards Track [Page 31] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[31ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809b
}
REFERENCE、「AppleTalk Phase2プロトコルSpecification、ドキュメントADPA#C0144LL/A.」 ::= ether2 0x809b--、[0.0.128.155]vsnap(0×080007)0x809b
5.4. L4: Children of L3 Protocols
5.4. L4: L3プロトコルの子供
5.4.1. ICMP
5.4.1. ICMP
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol."
REFERENCE
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 }
icmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「インターネットメッセージ制御プロトコル。」 REFERENCE、「RFC792[RFC792]はインターネット・コントロール・メッセージ・プロトコルを定義します」。 ::= ip1
5.4.2. TCP
5.4.2. TCP
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol."
CHILDREN
"Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC 793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
tcpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「転送管理プロトコル。」 CHILDREN、「TCPの子供はRFC793の指定されるとしての16ビットのDestination Port値によって特定されます」。 それらは、[0.0.a.b]('a'はMSBと'b'である)がDestination Port価値のLSBであるので、コード化されます。 両方のバイトはネットワークバイトオーダーでコード化されます。 例えば、以下のprotocolDirId-断片 0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793 [RFC793] defines the Transmission Control Protocol.
telnetのカプセル化は」 (ether2.ip.tcp.telnet)REFERENCEについて議定書の中で述べます。「特定、「RFC793[RFC793]は通信制御プロトコルを定義します」。
The following URL defines the authoritative repository for
reserved and registered TCP port values:
以下のURLは予約されて登録されたTCPポート値のために正式の倉庫を定義します:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 6 }
" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers ":、:= ip6
Bierman & Iddon Standards Track [Page 32] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[32ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.4.3. UDP
5.4.3. UDP
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol."
CHILDREN
"Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
udpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「ユーザデータグラムプロトコル。」 CHILDREN、「UDPの子供はRFC768の指定されるとしての16ビットのDestination Port値によって特定されます」。 それらは、[0.0.a.b]('a'はMSBと'b'である)がDestination Port価値のLSBであるので、コード化されます。 両方のバイトはネットワークバイトオーダーでコード化されます。 例えば、以下のprotocolDirId-断片 0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768 [RFC768] defines the User Datagram Protocol.
「SNMP(ether2.ip.udp.snmp)のカプセル化を特定する」、REFERENCE、「RFC768[RFC768]はユーザー・データグラム・プロトコルを定義します」。
The following URL defines the authoritative repository for
reserved and registered UDP port values:
以下のURLは予約されて登録されたUDPポート値のために正式の倉庫を定義します:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 17 }
" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers ":、:= ip17
5.5. L5: Application Layer Protocols
5.5. L5: 応用層プロトコル
5.5.1. FTP
5.5.1. FTP
5.5.1.1. FTP-DATA
5.5.1.1. FTPデータ
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
ftp-データプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「ファイル転送プロトコルデータは移植する」記述。 FTP Serverはデフォルトデータ接続ポートを処理します。 "REFERENCE"RFC959[RFC959]はFile Transferプロトコルを定義します。 「FTPデータ接続に関する詳細について[RFC959]のセクション3.2を参照してください。」 ::= tcp20
Bierman & Iddon Standards Track [Page 33] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[33ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.1.2. FTP Control
5.5.1.2. FTPコントロール
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Control Port; An FTP client initiates
an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }
ftpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「ファイル転送プロトコルコントロールは移植する」記述。 「FTPクライアントはユーザポート(U)からこのポートまでのFTPコマンドを送ることによって、FTPコントロール接続を開始します。」 REFERENCE、「RFC959[RFC959]はFile Transferプロトコルを定義します」。 ::= tcp21
5.5.2. Telnet
5.5.2. telnet
telnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Telnet Protocol; The purpose of the TELNET Protocol is to
provide a fairly general, bi-directional, eight-bit byte oriented
communications facility. Its primary goal is to allow a standard
method of interfacing terminal devices and terminal-oriented
processes to each other. "
REFERENCE
"RFC 854 [RFC854] defines the basic Telnet Protocol."
::= { tcp 23 }
telnetプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「テルネット・プロトコル」。 TELNETプロトコルの目的はかなり一般的で、双方向の、そして、8ビットのバイト指向のコミュニケーション施設を提供することです。 プライマリ目標は端末装置と端末指向のプロセスを互いに連結する標準方法を許容することです。 「"REFERENCE"RFC854[RFC854]は基本的なテルネット・プロトコルを定義します。」 ::= tcp23
5.5.3. SMTP
5.5.3. SMTP
smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC 821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
::= { tcp 25 }
smtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「簡単な郵便為替は議定書の中で述べる」記述。 「SMTPコントロールとデータメッセージをこのポートに送ります。」 REFERENCE、「RFC821[RFC821]は基本的なシンプルメールトランスファプロトコルを定義します」。 ::= tcp25
Bierman & Iddon Standards Track [Page 34] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[34ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.4. DNS
5.5.4. DNS
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC 1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }
ドメインプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ドメイン名サービスプロトコル」。 DNSはUDP[RFC768]かTCP[RFC793]のどちらかによって輸送されるかもしれません。 「輸送がUDPであるなら、長さ512バイトに制限されたDNS要求をこのポートに送るかもしれません。」 REFERENCE、「RFC1035[RFC1035]はBootstrapプロトコルを定義します」。 ::= udp53、tcp53
5.5.5. BOOTP
5.5.5. BOOTP
5.5.5.1. Bootstrap Server Protocol
5.5.5.1. サーバプロトコルを独力で進んでください。
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }
bootpsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「プロトコルサーバプロトコルを独力で進みます」。 「BOOTP Clientsは要求(通常、放送する)をbootpsポートに送ります。」 REFERENCE、「RFC951[RFC951]はBootstrapプロトコルを定義します」。 ::= udp67
5.5.5.2. Bootstrap Client Protocol
5.5.5.2. クライアントプロトコルを独力で進んでください。
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }
bootpcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「プロトコルクライアントプロトコルを独力で進みます」。 「この仕向港を使用することでBOOTP Server回答をBOOTP Clientに送ります。」 REFERENCE、「RFC951[RFC951]はBootstrapプロトコルを定義します」。 ::= udp68
Bierman & Iddon Standards Track [Page 35] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[35ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.6. TFTP
5.5.6. TFTP
tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
TFTP Timeout Interval and Transfer Size Options."
tftpプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES、記述「些細なファイル転送プロトコル」。 69を移植するためにそれぞれのTFTPトランザクションの最初のパケットだけを送るでしょう。 「tracksSessions属性が設定されるなら、それぞれのTFTPトランザクションのためのパケットはtftpの結果と考えられるでしょう、その後のパケットでコード化される登録されていないポートナンバーの代わりに。」 REFERENCE、「RFC1350[RFC1350]はTFTPプロトコル(改正2)を定義します」。 RFC1782[RFC1782]はTFTP Option Extensionsを定義します。 RFC1783[RFC1783]はTFTP Blocksize Optionを定義します。 「RFC1784[RFC1784]はTFTP Timeout IntervalとTransfer Size Optionsを定義します。」
::= { udp 69 }
::= udp69
5.5.7. HTTP
5.5.7. HTTP
www-http PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol; "
REFERENCE
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0)."
::= { tcp 80 }
www-httpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ハイパーテキスト転送プロトコル」。 「"REFERENCE"RFC1945[RFC1945]はハイパーテキストTransferプロトコル(HTTP/1.0)を定義します。」 ::= tcp80
5.5.8. POP3
5.5.8. POP3
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC 1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
::= { tcp 110 }
pop3プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「郵便局は議定書を作ります--バージョン3。」 「クライアントはPOP3サーバでこの目的地ポートナンバーを使用することによって、関係を樹立します。」 REFERENCE、「RFC1725[RFC1725]はポストオフィスプロトコルのバージョン3を定義します」。 ::= tcp110
Bierman & Iddon Standards Track [Page 36] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[36ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.9. SUNRPC
5.5.9. SUNRPC
sunrpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0) -- port mapper function numbers
}
DESCRIPTION
"SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN
Specific RPC functions are represented as children of the sunrpc
protocol. Each 'RPC function protocol' is identified by its
function number assignment. RPC function number assignments are
defined by different naming authorities, depending of the
function identifier value.
From [RFC1831]:
hasChildren(0)--マッパ機能番号を移植してください。sunrpcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「太陽遠隔手続き呼び出しプロトコル。」 「ポートマッパ機能要求をこの仕向港に送ります。」 sunrpcの子供が議定書を作るとき、CHILDREN Specific RPC機能は表されます。 各'RPC機能プロトコル'は機能数の課題で特定されます。 機能識別子価値をよって、RPC機能数の課題は異なった命名当局によって定義されます。 [RFC1831]から:
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
以下のチャートに応じて、16進20000000のグループにおける外にプログラム番号を与えます(10進536870912):
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
0-- rpc@sun.com 20000000によって定義された1fffffff--ユーザ40000000によって定義された3fffffff--5fffffffの一時的な60000000--7fffffffは80000000を予約しました--9fffffffはa0000000を予約しました--bfffffffはdfffffffがe0000000を予約したというffffffffが予約したc0000000を予約しました。
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
'sunrpc'の子供がコード化される、[0.0 .0 .111('sunrpc'のためのプロトコル識別子コンポーネント)は][a.b.c.d]で続きました。そこでは、a.b.c.dはRPCプログラム番号がネットワークバイトオーダーでコード化した32ビットのバイナリーです。 例えば、以下のprotocolDirID-断片値 0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
NFS機能(議定書を作る)を定義します。
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'.
REFERENCE
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
::= { udp 111 }
ベース10形式におけるRPC機能番号に従って'sunrpc'が続いたので、子供は命名されます。 例えば、NFSは命名されるでしょう: 'sunrpc100003'。 REFERENCE、「RFC1831[RFC1831]はRemote Procedure Callプロトコルバージョン2を定義します」。 RPC Functionsの正式のリストはURLによって特定されます: " ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers ":、:= udp111
Bierman & Iddon Standards Track [Page 37] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[37ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.10. NFS
5.5.10. NFS
nfs PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"The first packet in an NFS transaction is sent to the port-
mapper, and therefore decoded statically by monitoring RFC
portmap requests [RFC1831]. Any subsequent NFS fragments must be
decoded and correctly identified by 'remembering' the port
assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
nfsプロトコル-IDENTIFIER PARAMETERS countsFragments(0)、ATTRIBUTES、記述「Sunネットワークファイルシステム(NFS)」。 DECODING、「NFSトランザクションにおける最初のパケットは、ポートマッパに送られて、したがって、RFC portmap要求[RFC1831]をモニターすることによって、静的に解読されます」。 どんなその後のNFS断片も、解読されてそれぞれのRPCファンクションコールに使用されるポート課題が'覚えている'であることによって、正しく特定していなければなりません(RPC Specificationバージョン2[RFC1831]における手順によると、特定されるように)。
The 'countsFragments(0)' PARAMETER bit is used to indicate
whether the probe can (and should) monitor portmapper activity to
correctly attribute all NFS packets."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
「'countsFragments(0)'PARAMETERビットは徹底的調査がそうすることができるか否かに関係なく、(and should)が正しくすべてのNFSパケットを結果と考えるためにポートマッパー活動をモニターするのを示すのに使用されます。」 REFERENCE、「NFSバージョン3プロトコルSpecificationはRFC1813[RFC1813]で定義されます」。 ::= sunrpc100003--、[0.1、.134、.163]
5.5.11. SNMP
5.5.11. SNMP
5.5.11.1. SNMP Request/Response
5.5.11.1. SNMP要求/応答
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}
snmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なネットワーク管理プロトコル。」 SNMPv1とSNMPv2プロトコルバージョンを含んでいます。 「SNMP罠パケットを含んでいません。」 REFERENCE、「SNMP SMIはRFC1902[RFC1902]で定義されます」。 SNMPプロトコルはRFC1905[RFC1905]で定義されます。 輸送マッピングはRFC1906[RFC1906]で定義されます。 RFC1420(IPXの上のSNMP)[RFC1420]。 「RFC1419(AppleTalkの上のSNMP)[RFC1419]。」 ::= udp161、ipx 0x900f--、[0.0.144.15]atalk8
Bierman & Iddon Standards Track [Page 38] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[38ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
5.5.11.2. SNMP Trap
5.5.11.2. SNMP罠
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
ipx 0x9010,
atalk 9
}
snmptrapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なネットワーク管理プロトコル罠ポート。」 REFERENCE、「SNMP SMIはRFC1902[RFC1902]で定義されます」。 SNMPプロトコルはRFC1905[RFC1905]で定義されます。 輸送マッピングはRFC1906[RFC1906]で定義されます。 RFC1420(IPXの上のSNMP)[RFC1420]。 「RFC1419(AppleTalkの上のSNMP)[RFC1419]。」 ::= udp162、ipx0x9010、atalk9
6. Acknowledgements
6. 承認
This document was produced by the IETF RMONMIB Working Group.
このドキュメントはIETF RMONMIB作業部会によって製作されました。
The authors wish to thank the following people for their contributions to this document:
作者はこのドキュメントへの彼らの貢献について以下の人々に感謝したがっています:
Anil Singhal
Frontier Software Development, Inc.
コマツナギSinghal国境のソフトウェア開発Inc.
Jeanne Haney
Bay Networks
ジャンヌヘーニーベイネットワークス
Dan Hansen
Network General Corp.
ダンハンセンネットワーク一般社
Bierman & Iddon Standards Track [Page 39] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[39ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
7. References
7. 参照
[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[RFC791]
Postel, J., ed., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, USC/Information Sciences
Institute, September 1981.
[RFC791]ポステル、J.(教育)、「インターネットは議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC791、USC/情報Sciences Institute、1981年9月。
[RFC792]
Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[RFC792]ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、科学が設けるUSC/情報、1981年9月。
[RFC793]
Postel, J., "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 793, USC/Information Sciences
Institute, September 1981.
[RFC793]ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC793、科学が設けるUSC/情報、1981年9月。
[RFC821]
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[RFC826]
Plummer, D., "An Ethernet Address Resolution Protocol or
"Converting Network Protocol Addresses to 48-bit Ethernet Addresses
for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS,
November 1982.
[RFC826]プラマー、D.、「イーサネットは解決プロトコルか「イーサネットハードウェアの上でトランスミッションのための48ビットのイーサネットアドレスにネットワーク・プロトコルアドレスを変換すること」を扱います、STD37、RFC826、MIT-LCS、1982年11月。」
[RFC854]
Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, ISI, May 1983.
[RFC854] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854、ISI)は1983がそうするかもしれません。
[RFC894]
Hornig, C., "A Standard for the Transmission of IP Datagrams over
Ethernet Networks", RFC 894, Symbolics, April 1984.
[RFC894] ホーニッグ、C.、「イーサネットネットワークの上のIPデータグラムの送信の規格」、RFC894、信条学、1984年4月。
[RFC951]
Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsytems, September 1985.
[RFC951] 耕地、B.とJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とRFC951とスタンフォードと太陽Microsytems、1985年9月。
[RFC959]
Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8,
RFC 959, USC/Information Sciences Institute, October 1985.
[RFC959] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、STD8、RFC959、科学が1985年10月に設けるUSC/情報。
Bierman & Iddon Standards Track [Page 40] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[40ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[RFC1157]
Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[RFC1157]ケース、J.、M.ヒョードル、M.Schoffstall、J.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "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.
[RFC1213]のMcCloghrie、K.とM.ローズ、エディターズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、ヒューズLANシステム、国際言語運用機構、1991年3月。
[RFC1350]
Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
1992.
[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、RFC1350、MIT、1992年7月。
[RFC1419]
Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419,
Novell, Inc., Apple Computer, Inc., March 1993.
[RFC1419] Minshall、G.とM.リッター、「AppleTalkの上のSNMP」RFC1419、ノベルInc.、アップル・コンピューターInc.、1993年3月。
[RFC1420]
Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
[RFC1420]Bostock、S.、「IPXの上のSNMP」、RFC1420、ノベルInc.、1993年3月。
[RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[RFC1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[RFC1725]
Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
[RFC1725] マイアーズ、J.とM.バラ、「バージョン3インチ、RFC POP--1725、カーネギー・メロン、ドーヴァーはコンサルティングを浜に引き上げます、1994年11月。」
[RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
Mellon University, February 1995.
1995年2月の[RFC1757]S.Waldbusser、「リモートネットワーク監視MIB」、RFC1757カーネギーメロン大学。
[RFC1782]
Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1782] マルキン、G.とA.ハーキン、T「TFTPオプション拡張子」、RFC1782、Xylogics Inc.、ヒューレットパッカード社、1995年3月。
[RFC1783]
Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1783] マルキン、G.とA.ハーキン、T「TFTP BlockOptionオプション」、RFC1783、Xylogics Inc.、ヒューレットパッカード社、1995年3月。
Bierman & Iddon Standards Track [Page 41] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[41ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
[RFC1784]
Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
1995.
[RFC1784] マルキン、G.、およびA.ハーキン、「TFTPタイムアウト間隔と転送サイズオプション」(RFC1784、Xylogics Inc.、ヒューレットパッカード社)は1995を行進させます。
[RFC1800]
Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
RFC 1920, IAB, March 1996.
[RFC1800] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、STD1、RFC1920、IAB、1996年3月。
[RFC1831]
Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
1831, Sun Microsystems, Inc., August 1995.
[RFC1831] Srinivasan、R.、「遠隔手続き呼び出しプロトコルバージョン2インチ、RFC1831、サン・マイクロシステムズ・インク、1995年8月。」
[RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[RFC1902] SNMPv2作業部会、Case、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」、RFC1902(1996年1月)。
[RFC1903]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903] SNMPv2作業部会、Case、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「Simple Network Managementプロトコルのバージョン2のための原文のConventions(SNMPv2)」、RFC1903(1996年1月)。
[RFC1904]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[RFC1904] SNMPv2作業部会、Case、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「Simple Network Managementプロトコルのバージョン2のための順応Statements(SNMPv2)」、RFC1904(1996年1月)。
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]SNMPv2作業部会、Case(J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためにOperationsについて議定書の中で述べます」、RFC1905、1996年1月。
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC1945]
Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995.
[RFC1945]のバーナーズ・リー、T.とR.フィールディング、「ハイパーテキストはHTTP/1インチと、RFC1945、UC MIT/アーバイン1995年11月にプロトコルを移します」。
[RMON2]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
ietf-rmonmib-rmon2-03.txt, International Network Services, January
1996.
「リモートネットワーク監視MIB(RMON-2)」という[RMON2]S.Waldbusserは1996年1月にietf-rmonmib-rmon2-03.txt、国際Network Servicesを作成します。
Bierman & Iddon Standards Track [Page 42] RFC 2074 RMON Protocol Identifiers January 1997
Bierman&Iddon標準化過程[42ページ]RFC2074RMONは識別子1997年1月に議定書を作ります。
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Authors' Addresses
9. 作者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
アンディBiermanシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: 408-527-3711 EMail: abierman@cisco.com
以下に電話をしてください。 408-527-3711 メールしてください: abierman@cisco.com
Robin Iddon 3Com/AXON 40/50 Blackfrias Street Edinburgh, UK
ロビンIddon 3Com/AXON40/50Blackfrias通りエディンバラ、イギリス
Phone: +44 131.558.3888 EMail: robin_iddon@3mail.3com.com
以下に電話をしてください。 +44 131.558 .3888 メール: robin_iddon@3mail.3com.com
Bierman & Iddon Standards Track [Page 43]
Bierman&Iddon標準化過程[43ページ]
一覧
スポンサーリンク
