[要約] RFC 2895は、リモートネットワーク監視MIBプロトコル識別子の参照に関する情報を提供する。このRFCの目的は、ネットワーク管理者がリモートネットワーク監視を効果的に行うためのプロトコル識別子の使用方法を明確にすることである。
Network Working Group A. Bierman
Request for Comments: 2895 C. Bucci
Obsoletes: 2074 Cisco Systems, Inc.
Category: Standards Track R. Iddon
3Com, Inc.
August 2000
Remote Network Monitoring MIB Protocol Identifier Reference
リモートネットワーク監視MIBプロトコル識別子参照
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring Management Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.
このメモは、RMON-2 MIB（リモートネットワーク監視管理情報ベース）[RFC2021]に見られるプロトコルディル化可能なインデックス値のエンコードに特に使用するために、特にプロトコルカプセル化のプロトコル層を説明する表記を定義します。標準のプロトコルディレクトリベースレイヤー識別子の定義も含まれています。
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON Protocol Identifier Macros document [RFC2896] now contains the non-normative portion of that specification.
RMONプロトコル識別子ドキュメント[RFC2074]の最初のバージョンは、標準トラック参照部分（このドキュメント）と情報ドキュメントに分割されています。RMONプロトコル識別子マクロスドキュメント[RFC2896]には、その仕様の非規範的部分が含まれるようになりました。
This document obsoletes RFC 2074.
このドキュメントは、RFC 2074を廃止します。
Table of Contents
目次
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
The SNMP Management Framework presently consists of five major components:
SNMP管理フレームワークは現在、5つの主要なコンポーネントで構成されています。
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC 2571 [RFC2571]に記載されている全体的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
o 管理を目的としたオブジェクトとイベントを説明および名前を付けるためのメカニズム。この管理情報の最初のバージョン（SMI）はSMIV1と呼ばれ、STD 16、RFC 1155 [RFC1155]、STD 16、RFC 1212 [RFC1212]およびRFC 1215 [RFC1215]で説明されています。SMIV2と呼ばれる2番目のバージョンは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [RFC2580]に記載されています。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o 管理情報を転送するためのメッセージプロトコル。SNMPメッセージプロトコルの最初のバージョンはSNMPV1と呼ばれ、STD 15、RFC 1157 [RFC1157]で説明されています。インターネット標準トラックプロトコルではないSNMPメッセージプロトコルの2番目のバージョンは、SNMPV2Cと呼ばれ、RFC 1901 [RFC1901]およびRFC 1906 [RFC1906]で説明されています。メッセージプロトコルの3番目のバージョンはSNMPV3と呼ばれ、RFC 1906 [RFC1906]、RFC 2572 [RFC2572]およびRFC 2574 [RFC2574]で説明されています。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905].
o 管理情報にアクセスするためのプロトコル操作。プロトコル操作の最初のセットと関連するPDU形式は、STD 15、RFC 1157 [RFC1157]で説明されています。プロトコル操作の2番目のセットと関連するPDU形式は、RFC 1905 [RFC1905]で説明されています。
o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575].
o RFC 2573 [RFC2573]に記載されている一連の基本的なアプリケーションと、RFC 2575 [RFC2575]で説明されているビューベースのアクセス制御メカニズム。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
現在のSNMP管理フレームワークのより詳細な紹介は、RFC 2570 [RFC2570]にあります。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されます。
This memo does not specify a MIB module.
このメモは、MIBモジュールを指定しません。
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
RMON-2 MIB [RFC2021]は、階層的にフォーマットされたオクテット文字列を使用して、プロトコルディル化可能な個々のプロトコルカプセルをグローバルに識別します。
This guide contains algorithms and the authoritative set of base layer protocol identifier macros, for use within INDEX values in the protocolDirTable.
このガイドには、プロトコルディル化可能なインデックス値内で使用するために、アルゴリズムと基本層プロトコル識別子マクロの権威あるセットが含まれています。
This is the second revision of this document, and is intended to replace the first half of the first RMON-2 Protocol Identifiers document. [RFC2074].
これはこのドキュメントの2番目の改訂であり、最初のRMON-2プロトコル識別子ドキュメントの前半を置き換えることを目的としています。[RFC2074]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Several terms are used throughout this document, as well as in the RMON-2 MIB [RFC2021], that should be introduced:
このドキュメント全体と、RMON-2 MIB [RFC2021]でいくつかの用語が使用されています。
parent protocol: Also called 'parent'; The encapsulating protocol identifier for a specific protocol layer, e.g., IP is the parent protocol of UDP. Note that base layers cannot have parent protocols. This term may be used to refer to a specific encapsulating protocol, or it may be used generically to refer to any encapsulating protocol.
親プロトコル：「親」とも呼ばれます。特定のプロトコル層のカプセル化プロトコル識別子、たとえば、IPはUDPの親プロトコルです。ベースレイヤーには親プロトコルがないことに注意してください。この用語は、特定のカプセル化プロトコルを参照するために使用される場合があります。または、任意のカプセル化プロトコルを参照するために一般的に使用される場合があります。
child protocol: Also called 'child'; An encapsulated protocol identifier for a specific protocol layer. e.g., UDP is a child protocol of IP. This term may be used to refer to a specific encapsulated protocol, or it may be used generically to refer to any encapsulated protocol.
子プロトコル：「子」とも呼ばれます。特定のプロトコル層のカプセル化プロトコル識別子。たとえば、UDPはIPの子プロトコルです。この用語は、特定のカプセル化されたプロトコルを参照するために使用される場合があります。または、カプセル化されたプロトコルを参照するために一般的に使用される場合があります。
layer-identifier: An octet string fragment representing a particular protocol encapsulation layer or sub-layer. A fragment consists of exactly four octets, encoded in network byte order. If present, child layer-identifiers for a protocol MUST have unique values among each other. (See section 3.3 for more details.)
レイヤーIdentifier：特定のプロトコルカプセル化レイヤーまたはサブ層を表すオクテット文字列フラグメント。フラグメントは、ネットワークバイトの順序でエンコードされた正確な4オクテットで構成されています。存在する場合、プロトコルの子層識別子は、互いに一意の値を持たなければなりません。（詳細については、セクション3.3を参照してください。）
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 [RFC2021] 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 [RFC2021]で使用される場合があるため、完全に指定されたプロトコル識別子文字列に名前を付けることに注意してください。このような場合、プロトコル識別子文字列は、その最上層層に命名されています。指定されたプロトコルは、そのプロトコルの任意のカプセル化についても指す場合があります。
protocol-identifier string: An octet string representing a particular protocol encapsulation, as specified by the encoding rules in this document. This string is identified in the RMON-2 MIB [RFC2021] as the protocolDirID object. A protocol-identifier string is composed of one or more layer-identifiers read from left to right. The left-most layer-identifier specifies a base layer encapsulation. Each layer-identifier to the right specifies a child layer protocol encapsulation.
プロトコル識別子文字列：このドキュメントのエンコーディングルールで指定されているように、特定のプロトコルカプセル化を表すオクテット文字列。この文字列は、RMON-2 MIB [RFC2021]でプロトコルディリドオブジェクトとして識別されます。プロトコル識別子文字列は、左から右に読み取られた1つ以上のレイヤー識別子で構成されています。左est層識別子は、ベースレイヤーのカプセル化を指定します。右側の各層識別子は、子層プロトコルのカプセル化を指定します。
protocol-identifier macro: Also called a PI macro; A macro-like textual construct used to describe a particular networking protocol. Only protocol attributes which are important for RMON use are documented. Note that the term 'macro' is historical, and PI macros are not real macros, nor are they ASN.1 macros. The current set of published RMON PI macros can be found in the RMON Protocol Identifier Macros document [RFC2896].
Protocol-Identifierマクロ：PIマクロとも呼ばれます。特定のネットワークプロトコルを記述するために使用されるマクロのようなテキスト構成。RMON使用に重要なプロトコル属性のみが文書化されています。「マクロ」という用語は歴史的であり、PIマクロは実際のマクロではなく、1マクロでもないことに注意してください。公開されているRMON PIマクロの現在のセットは、RMONプロトコル識別子マクロスドキュメント[RFC2896]に記載されています。
The PI macro serves several purposes:
PIマクロはいくつかの目的を果たします。
- Names the protocol for use within the RMON-2 MIB [RFC2021]. - Describes how the protocol is encoded into an octet string. - Describes how child protocols are identified (if applicable), and encoded into an octet string. - Describes which protocolDirParameters are allowed for the protocol. - Describes how the associated protocolDirType object is encoded for the protocol. - Provides reference(s) to authoritative documentation for the protocol.
- RMON-2 MIB [RFC2021]内で使用するプロトコルに名前を付けます。 - プロトコルがオクテット文字列にエンコードされる方法を説明します。-Childプロトコルがどのように識別されるか（該当する場合）、およびOctet Stringにエンコードされる方法について説明します。 - プロトコルに許可されているプロトコルディルパラメーターを説明します。 - 関連するプロトコルディルタイプオブジェクトがプロトコル用にエンコードされる方法を説明します。 - プロトコルの権威あるドキュメントへの参照を提供します。
protocol-variant-identifier macro: Also called a PI-variant macro; A special kind of PI macro, used to describe a particular protocol layer, which cannot be identified with a deterministic, and (usually) hierarchical structure, like most networking protocols.
Protocol-Variant-Identifier Macro：Pi-Variant Macroとも呼ばれます。特定のプロトコル層を記述するために使用される特別な種類のPIマクロ。これは、ほとんどのネットワーキングプロトコルと同様に、決定論的で（通常）階層構造で識別できません。
Note that the PI-variant macro and the PI-macro are defined with a single set of syntax rules (see section 3.2), except that different sub-clauses are required for each type.
Pi-Variant MacroとPi-Macroは、各タイプに異なるサブクロースが必要であることを除いて、単一の構文ルールのセット（セクション3.2を参照）で定義されていることに注意してください。
A protocol identified with a PI-variant macro is actually a variant of a well known encapsulation that may be present in the protocolDirTable. This 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. (See section 3.2 for details.)
Pi変数マクロで識別されたプロトコルは、実際には、プロトコルディル化可能なものに存在する可能性のあるよく知られているカプセル化のバリアントです。これは、「適切なネットワークトラフィック」（たとえばそれらを運ぶパケット）の調査では実際に特定できないプロトコルを特定するために必要なIANAが割り当てられたプロトコルを文書化するために使用されます。他のすべてのプロトコル（適切なネットワークトラフィックの調査によって特定できます）は、プロトコル識別子マクロを使用して文書化する必要があります。（詳細については、セクション3.2を参照してください。）
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. (See section 3.2.6 for details.)
プロトコルパラメーター：プロトコル識別子の特定の層識別子に対応する単一のオクテット。このオクテットは、このエージェントが対応するプロトコルに提供している特別な機能または機能を示すビットマスクです。（詳細については、セクション3.2.6を参照してください。）
protocol-parameters string: An octet string, which contains one protocol-parameter for each layer-identifier in the protocol-identifier. This string is identified in the RMON-2 MIB [RFC2021] as the protocolDirParameters object. (See the section 3.2.6 for details.)
プロトコルパラメーター文字列：プロトコル識別子の各レイヤー識別子に1つのプロトコルパラメーターを含むOctet文字列。この文字列は、RMON-2 MIB [RFC2021]でProtoColdIrParametersオブジェクトとして識別されます。（詳細については、セクション3.2.6を参照してください。）
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 section 7.7 of RFC 1902 [RFC1902].
ProtoColdirtable Index：RFC 1902 [RFC1902]のセクション7.7のエンコーディングルールに従って、インデックス値に変換されたプロトコル識別子およびプロトコルパラメータオクテット文字列ペア。
pseudo-protocol: A convention or algorithm used only within this document for the purpose of encoding protocol-identifier strings.
擬似プロトコル：プロトコル識別子文字列をエンコードする目的で、このドキュメント内でのみ使用される慣習またはアルゴリズム。
protocol encapsulation tree: Protocol encapsulations can be organized into an inverted tree. The nodes of the root are the base encapsulations. The children nodes, if any, of a node in the tree are the encapsulations of child protocols.
プロトコルカプセル化ツリー：プロトコルカプセルは、逆ツリーに編成できます。ルートのノードは、ベースのカプセルです。ツリー内のノードの子供ノードは、児童プロトコルのカプセル化です。
This document is intended to identify the encoding rules for the OCTET STRING objects protocolDirID and protocolDirParameters. RMON-2 tables, such as those in the new Protocol Distribution, Host, and Matrix groups, use a local INTEGER INDEX (protocolDirLocalIndex) rather than complete protocolDirTable INDEX strings, to identify protocols for counting purposes. Only the protocolDirTable uses the protocolDirID and protocolDirParameters strings described in this document.
このドキュメントは、Octet String Objects ProtocoldiridおよびProtocoldirParametersのエンコーディングルールを識別することを目的としています。新しいプロトコル分布、ホスト、およびマトリックスグループのようなRMON-2テーブルは、完全なプロトコルディル化可能なインデックス文字列ではなく、ローカル整数インデックス（Protocoldirlocalindex）を使用して、カウント用のプロトコルを特定します。このドキュメントで説明されているプロトコルディリドおよびプロトコルディルパラメーター文字列を使用しているのは、プロトコルディアブルのみです。
This document is intentionally separated from the RMON-2 MIB objects [RFC2021] to allow updates to this document without any republication of MIB objects.
このドキュメントは、RMON-2 MIBオブジェクト[RFC2021]から意図的に分離されており、MIBオブジェクトの再公開なしにこのドキュメントの更新を許可しています。
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 the 'interesting' protocols on which the intended applications depend.
このドキュメントでは、プロトコルディル化可能な自動配信と自動入力については説明していません。この機能は、RMON標準によって明示的に定義されていません。エージェントは、意図したアプリケーションが依存する「興味深い」プロトコルにディレクトリに埋め込む必要があります。
The original RMON Protocol Identifiers document [RFC2074] contains the protocol directory reference material, as well as many examples of protocol identifier macros.
元のRMONプロトコル識別子ドキュメント[RFC2074]には、プロトコル識別子マクロの多くの例と、プロトコルディレクトリ参照資料が含まれています。
These macros have been moved to a separate document called the RMON Protocol Identifier Macros document [RFC2896]. This will allow the normative text (this document) to advance on the standards track with the RMON-2 MIB [RFC2021], while the collection of PI macros is maintained in an Informational RFC.
これらのマクロは、RMONプロトコル識別子マクロドキュメント[RFC2896]と呼ばれる別のドキュメントに移動されました。これにより、規範的なテキスト（このドキュメント）がRMON-2 MIB [RFC2021]を使用して標準トラックを進めることができ、PIマクロのコレクションは情報RFCで維持されます。
The PI Macros document is intentionally separated from this document to allow updates to the list of published PI macros without any republication of MIB objects or encoding rules. Protocol Identifier macros submitted from the RMON working group and community at large (to the RMONMIB WG mailing list at 'rmonmib@ietf.org') will be collected, screened by the RMONMIB working group, and (if approved) added to a subsequent version of the PI Macros document.
PI MacroSドキュメントは、MIBオブジェクトの再公開やエンコードルールの再公開なしに公開されたPIマクロのリストを更新できるようにするために、このドキュメントから意図的に分離されています。RMONワーキンググループとコミュニティ全体から提出されたプロトコル識別子マクロ（ 'rmonmib@ietf.org'のRmonmib WGメーリングリストに）が収集され、Rmonmibワーキンググループによってスクリーニングされ、（承認された場合）後続のバージョンに追加されますPIマクロドキュメントの。
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 www.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.htm.
マクロの送信は、ディレクトリ「ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/」の下のIANAのMIBファイルで収集されます。アーカイブ/ワーキンググループ/rmonmib/current/maillist.htm。
The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides RMON-like stats, host, matrix, and matrixTopN capability for NSAP address-based (ATM Adaption Layer 5, AAL-5) cell traffic.
ATMフォーラムには、NSAPアドレスベースにRMONのような統計、ホスト、マトリックス、およびマトリックストップン機能を提供する（ATMネットワーク用のリモートモニタリングMIB拡張機能」（ATM-RMON MIB）[AF-NM-Test-0080.000]を標準化しています（AF-NM-Test-0080.000]ATM適応層5、AAL-5）セルトラフィック。
It it possible to correlate ATM-RMON MIB data with packet-based RMON-2 [RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and 'portSelTable' are configured to provide the same level of port aggregation as used in the packet-based collection. This will require an ATM-RMON 'portSelectGroup' to contain a single port, in the case of traditional RMON dataSources.
ATM-RMON MIBデータをパケットベースのRMON-2 [RFC2021]コレクションと相関させることができますが、ATM-RMONの「PortselGrptable」と「PortselTable」が、同じレベルのポート集約を提供するように構成されている場合のみです。パケットベースのコレクション。これには、従来のRMONデータソースの場合、単一のポートを含むためにATM-RMONの「PortSelectGroup」が必要です。
The RMON PI document does not contain explicit PI macro support for "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, a probe must 'fit' the ATM encapsulation to one of the base layers defined in this document (i.e., llc, snap, or vsnap), regardless of how the raw data is obtained by the agent (e.g., VC-muxing vs. LLC-muxing, or routed vs. bridged formats). See section 3.2 for details on identifying and decoding a particular base layer.
RMON PIドキュメントには、「ATM適応レイヤー5に対するマルチプロトコルカプセル化」の明示的なPIマクロサポートは含まれていません[RFC1483]、またはATMフォーラム「ATM上のLANエミュレーション」（レーン）[AF-Lane-0021.000]。代わりに、プローブは、エージェントによって生データの取得方法に関係なく、このドキュメントで定義されているベースレイヤー（つまり、LLC、SNAP、またはVSNAP）で定義されているベースレイヤーの1つにATMのカプセル化を「適合」する必要があります（例：VC-Muxing vs。LLC-MUXING、またはルーティングvs.ブリッジ形式）。特定のベースレイヤーの識別とデコードの詳細については、セクション3.2を参照してください。
An NMS can determine some of the omitted encapsulation details by examining the interface type (ifType) of the dataSource for a particular RMON collection:
NMSは、特定のRMONコレクションのDataSourceのインターフェイスタイプ（IFType）を調べることにより、省略されたカプセル化の詳細の一部を決定できます。
RFC 1483 dataSource ifTypes: - aal5(49)
RFC 1483 DataSource IFTypes：-Aal5（49）
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
These dataSources require implementation of the ifStackTable from the Interfaces MIB [RFC2233]. It is possible that some implementations will use dataSource values which indicate an ifType of 'atm(37)' (because the ifStackTable is not supported), however this is strongly discouraged by the RMONMIB WG.
これらのデータソースには、インターフェイスMIB [RFC2233]からIFStackTableの実装が必要です。一部の実装では、「ATM（37）」のIFTypeを示すデータソース値を使用する可能性があります（IFStackTableがサポートされていないため）が、これはRmonMib WGによって強く落胆します。
The RMON-2 Application Layer (AL) and Network Layer (NL) (host/matrix/topN) tables require that octet counters be incremented by the size of the particular frame, not by the size of the frame attributed to a given protocol.
RMON-2アプリケーションレイヤー（AL）およびネットワークレイヤー（NL）（HOST/MATRIX/TOPN）テーブルは、特定のプロトコルに起因するフレームのサイズではなく、特定のフレームのサイズによってオクテットカウンターを増分する必要があります。
Probe implementations must use the AAL-5 frame size (not the AAL-5 payload size or encapsulated MAC frame size) as the 'frame size' for the purpose of incrementing RMON-2 octet counters (e.g., 'nlHostInOctets', 'alHostOutOctets').
プローブの実装では、RMON-2オクテットカウンター（「nlhostinoctets」、「alhostoutoctets」、「nlhostinoctetets」を増やす目的で、AAL-5フレームサイズ（AAL-5ペイロードサイズまたはカプセル化されたMacフレームサイズ）を「フレームサイズ」として使用する必要があります。）。
The RMONMIB WG has not addressed issues relating to packet capture of AAL-5 based traffic. Therefore, it is an implementation-specific matter whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3 or 802.5 traffic, or LANE traffic) are represented in the RMON-1 'captureBufferPacketData' MIB object. Normally, the first octet of the captured frame is the first octet of the destination MAC address (DA).
Rmonmib WGは、AAL-5ベースのトラフィックのパケットキャプチャに関する問題に対処していません。したがって、パディングオクテット（つまり、RFC 1483 VCマックス、ブリッジ802.3または802.5トラフィック、またはレーントラフィック）がRMON-1 'CaptureBufferPacketData' MIBオブジェクトに表されているかどうかは、実装固有の問題です。通常、キャプチャされたフレームの最初のオクテットは、宛先MACアドレス（DA）の最初のオクテットです。
The RMON Protocol Identifiers Reference 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プロトコル識別子リファレンスドキュメントは、RMON MIB内でプロトコルディル化可能で使用することを目的としています。これは、他のMIBには関係ありません。また、他のMIBで使用することを目的としています。
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.)
プロトコルディルタブルは、プロトコルディリドとプロトコルディルパラメーターの2つのオクテット文字列によってインデックス付けされています。テーブルインデックスをエンコードするために、各可変長文字列は、RFC 1902 [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 node in the 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.
最初のオクテット文字列（Protocoldirid）は、1つ以上の4-Octet「レイヤー識別子」で構成されています。文字列全体は、プロトコルカプセル化ツリーの特定のノードを一意に識別します。2番目のOctet文字列（ProtocoldirParameters）には、最初の文字列の4-OCTETレイヤー識別子ごとに1つの1つのオクテットプロトコル固有のパラメーターが含まれています。
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, then it must be defined as an 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
プロトコル層は通常、単一の32ビット値によって識別されます。各レイヤー識別子は、Protocoldirid Octet String Indexで4つのサブコンポーネント[A.B.C.D]としてエンコードされています。特定のプロトコル層を32ビットにエンコードできない場合、「IANASIGNED」プロトコルとして定義する必要があります（IANAが割り当てられたプロトコルの詳細については、以下を参照）。
The following figures show the differences between the OBJECT IDENTIFIER and OCTET STRING encoding of the protocol identifier string.
次の図は、プロトコル識別子文字列のオブジェクト識別子とオクテット文字列エンコードの違いを示しています。
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers required for the entire encapsulation of the named protocol. Note that the layer following the base layer usually identifies a network layer protocol, but this is not always the case, (most notably for children of the 'vsnap' base-layer).
nは、指定されたプロトコルのカプセル化全体に必要なプロトコル層識別子の数です。ベースレイヤーに続くレイヤーは通常、ネットワークレイヤープロトコルを識別しますが、これは必ずしもそうではありません（特に「VSNAP」ベースレイヤーの子供向け）。
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
When encoded in a protocolDirTable INDEX, each of the two strings must be preceded by a length sub-component. In this example, N equals '4', the first 'cnt' field would contain the value '16', and the second 'cnt' field would contain the value '4'.
プロトコルディル可能なインデックスにエンコードされた場合、2つの文字列のそれぞれの前に長さのサブコンポーネントが必要です。この例では、nは「4」に等しく、最初の「CNT」フィールドには値「16」が含まれ、2番目の「CNT」フィールドには値「4」が含まれます。
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
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つのカプセル化されたプロトコルを示していますが、実際には、ゼロ以外の数の層識別子が存在する場合がありますが、RFC 1902 [RFC1902]のセクション3.5で指定されているように、オブジェクト識別子の長さの制限によって理論的には制限されています。
The following PI identifier fragments are examples of some fully encoded protocolDirTable INDEX values for various encapsulations.
次のPi識別子フラグメントは、さまざまなカプセルの完全にエンコードされたプロトコルチャート可能なインデックス値の例です。
-- 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.1.0.0.8.0.0.0.0.6.0.0.0.0.80.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.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
-SNMP UDP/IP Over snap snap.ip.udp.snmp = 16.0.0.3.0.0.0.0.0.0.0.17.0.0.0.0.161.4.0.0.0.0.0.0.0.0.0.0
-- 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.ipx.snmp = 12.0.0.0.3.0.0.129.55.0.0.0.0.0.0.0.0.0.0.15.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0
-- SNMP over IPX over raw8023 ianaAssigned.ipxOverRaw8023.snmp = 12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-RAW8023を超えるIPXを超えるSNMP IANASIGNED.IPXOVERRAW8023.SNMP = 12.0.0.0.5.0.0.0.0.1.0.0.144.15.15.0.0.0
-- IPX over LLC llc.ipx = 8.0.0.0.2.0.0.0.224.2.0.0
-IPX Over LLC.IPX = 8.0.0.0.2.0.0.0.0.0.0.0.0
-- SNMP over UDP/IP over any link layer 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
-NMP UDP/IPを介したリンクレイヤーETHER2.IP.UDP.SNMP 16.1.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.0.0.0.0.0.0.0.0.0月
-- IP over any link layer; base encoding is IP over ether2 ether2.ip 8.1.0.0.1.0.0.8.0.2.0.0
- 任意のリンクレイヤー上のIP。ベースエンコーディングはEther2 Ether2.ip上のIPです。ip8.1.0.0.1.0.0.0.0.0.0.0
-- AppleTalk Phase 2 over ether2 ether2.atalk 8.0.0.0.1.0.0.128.155.2.0.0
-Ether2 Ether2.Atalk 8.0.0.0.1.0.0.128.155.2.0.0のAppleTalkフェーズ2
-- AppleTalk Phase 2 over vsnap vsnap.apple-oui.atalk 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
-VSNAP VSNAP.Apple-Oui.atalkを超えるAppleTalkフェーズ2 12.0.0.0.4.0.0.0.0.7.0.0.128.155.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
The following example is meant to introduce the protocol-identifier macro. This macro-like construct is used to represent both protocols and protocol-variants.
次の例は、プロトコル識別子マクロを導入することを目的としています。このマクロのような構成要素は、プロトコルとプロトコルバリアンの両方を表すために使用されます。
If the 'VariantOfPart' component of the macro is present, then the macro represents a protocol-variant instead of a protocol. This clause is currently used only for IANA assigned protocols, enumerated under the 'ianaAssigned' base-layer. The VariantOfPart component MUST be present for IANA assigned protocols.
マクロの「variantofpart」コンポーネントが存在する場合、マクロはプロトコルの代わりにプロトコル変数を表します。この句は現在、「IANASIGNED」ベースレイヤーの下で列挙されているIANAが割り当てられたプロトコルにのみ使用されています。VariantOfPartコンポーネントは、IANAが割り当てられたプロトコルに存在する必要があります。
The PI language defines the following keywords:
PI言語は次のキーワードを定義します。
ADDRESS-FORMAT ATTRIBUTES CHILDREN DECODING DESCRIPTION PARAMETERS PROTOCOL-IDENTIFIER REFERENCE VARIANT-OF
アドレスフォーマット属性子供のデコード説明パラメータープロトコル識別子参照バリアントのバリアント
The PI language defines the following punctuation elements:
PI言語は、次の句読点要素を定義します。
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
An extended form of the BNF notation is used to specify the syntax of the PI language. The rules for this notation are shown below:
BNF表記の拡張形式を使用して、PI言語の構文を指定します。この表記法のルールを以下に示します。
* Literal values are specified in quotes, for example "REFERENCE"
* リテラル値は、「参照」などの引用符で指定されています
* Non-terminal items are surrounded by less than (<) and greater than (>) characters, for example <parmList>
* 非ターミナルアイテムは、（<）未満と（>）以上の文字に囲まれています。たとえば、<parmlist>
* Terminal items are specified without surrounding quotes or less than and greater than characters, for example 'lcname'
* ターミナルアイテムは、周囲の引用符なしで指定されているか、文字以下の文字よりも大きく、たとえば「lcname」は指定されています。
* A vertical bar (|) is used to indicate a choice between items, for example 'number | hstr'
* 垂直バー（|）は、たとえば 'number |などのアイテム間の選択を示すために使用されます。HSTR '
* Ellipsis are used to indicate that the previous item may be repeated one or more times, for example <parm>...
* Ellipsisは、以前のアイテムが1回以上繰り返される可能性があることを示すために使用されます。たとえば、<Parm> ...
* Square brackets are used to enclose optional items, for example [ "," <parm> ]
* 正方形のブラケットは、["、" <parm>]など、オプションのアイテムを囲むために使用されます。
* An equals character (=) is used to mean "defined as," for example '<protoName> = pname'
* equals文字（=）は、たとえば '<protoname> = pname'など、「定義されている」という意味に使用されます。
The following are "terminals" of the grammar and are identical to the same lexical elements from the MIB module language, except for hstr and pname:
以下は文法の「端子」であり、HSTRとPNAMEを除き、MIBモジュール言語の同じ語彙要素と同じです。
<lc> = "a" | "b" | "c" | ... | "z"
<uc> = "A" | "B" | "C" | ... | "Z"
<letter> = <lc> | <uc>
<digit> = "0" | "1" | ... | "9"
<hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
The following is the extended BNF notation for the grammar with starting symbol <piFile>:
以下は、開始シンボル<Pifile>を備えた文法の拡張BNF表記です。
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name <protoName> = pname
-protocol名<protoname> = pname
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- a non-negative number <nonNegNum> = number | hstr
- 非陰性番号<nonnegnum> = number |HSTR
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- comment
<two dashes> <text> <end-of-line>
The "protoName" value, called the "protocol name" shall be an ASCII string consisting of one up to 64 characters from the following:
「プロトコル名」と呼ばれる「プロトナーム」値は、以下から最大64文字からなるASCII文字列でなければなりません。
"A" through "Z" "a" through "z" "0" through "9" dash (-) underbar (_) asterisk (*) plus(+)
"a" sile "z" "a" z "" "" "" "" "" "" 0 "x" 9 "ダッシュ（ - ）アンダーバー（_）asterisk（*）plus（）
The first character of the protocol name is limited to one of the following:
プロトコル名の最初の文字は、次のいずれかに限定されています。
"A" through "Z" "a" through "z"
「z "" "a" sを通して "z" z "
"0" through "9"
「0」から「9」
This value SHOULD be the name or acronym identifying the protocol. Note that case is significant. The value selected for the 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. Likewise, children of UDP and TCP SHOULD be given names consistent with the port number name assignments found in:
IPプロトコルのフィールド値を定義するため、IPの子供のプロトコル識別子マクロには、この権威ある文書にあるプロトコル名と一致する名前を指定する必要があります。同様に、UDPおよびTCPの子供には、次のようなポート番号名の割り当てと一致する名前を指定する必要があります。
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
When the "well-known name" contains characters not allowed in protocol names, they MUST be changed to a dash character ("-") . In the event that the first character must be changed, the protocol name is prepended with the letter "p", so the former first letter may be changed to a dash.
「有名な名前」にプロトコル名で許可されていない文字が含まれている場合、それらはダッシュ文字（ " - "）に変更する必要があります。最初の文字を変更する必要がある場合、プロトコル名は文字「P」で準備されているため、前の最初の文字がダッシュに変更される場合があります。
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The following protocol names are legal:
たとえば、Z39.50はZ39-50になり、914C/gは914C-Gになります。次のプロトコル名は合法です。
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
Note that it is possible in actual implementation that different encapsulations of the same protocol (which are represented by different entries in the protocolDirTable) will be assigned the same protocol name. The protocolDirID INDEX value defines a particular protocol, not the protocol name string.
実際の実装において、同じプロトコルの異なるカプセル（プロトコルディルタブルの異なるエントリで表される）に同じプロトコル名が割り当てられることが可能であることに注意してください。プロトコルディリドインデックス値は、プロトコル名文字列ではなく、特定のプロトコルを定義します。
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.
参照プロトコル識別子マクロの条項（子供、住所形式など）は、「バリアント」プロトコルのセマンティクスが特定の条項で同一である場合、プロトコル変数識別子マクロで複製されるべきではありません。
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e. "PARAMETERS {}") MUST be present in a protocol-variant-identifier macro, and the 'ParamList' and 'AttrList' found in the reference protocol-identifier macro examined instead.
パラメーターと属性条項はプロトコル識別子に存在する必要があるため、空の「パラメーション」と「アトラットリスト」（つまり、「パラメーター{}」）はプロトコルvariant-Identifierマクロに存在する必要があります。代わりに調べた参照プロトコル識別子マクロで見つかった「アトラリスト」。
Note that if an '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.
他の文書化されたプロトコルのバリアントではない「ianasigned」プロトコルが定義されている場合、マクロのプロトコル変数識別子バージョンの代わりにプロトコル識別子マクロを使用する必要があることに注意してください。
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.
パラメーター句は、ネットワークバイトの順序で関連するプロトコルディルパラメーターオクテットに直接エンコードできるビット定義のリストです。ゼロ以上のビット定義が存在する場合があります。ビット0〜7のみが有効なエンコード値です。この句は、特定のプロトコルに許可されているビットセット全体を定義します。適合剤は、これらのパラメーターのゼロ以上のサブセットを実装することを選択できます。
By convention, the following common bit definitions are used by different protocols. These bit positions MUST NOT be used for other parameters. They MUST be reserved if not used by a given protocol.
慣習により、次の共通ビット定義は異なるプロトコルで使用されます。これらのビット位置は、他のパラメーターに使用してはなりません。特定のプロトコルで使用しない場合は、予約する必要があります。
Bits are encoded in a single octet. Bit 0 is the high order (left-most) bit in the octet, and bit 7 is the low order (right-most) bit in the first octet. Reserved bits and unspecified bits in the octet are set to zero.
ビットは単一のオクテットでエンコードされます。ビット0は、オクテットの高次（左最大）ビットであり、ビット7は最初のオクテットの低い（右右）ビットです。オクテットの予約ビットと不特定のビットはゼロに設定されています。
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
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).
The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but may be equal to zero (empty).
パラメーター節は、すべてのプロトコル識別子マクロ宣言に存在する必要がありますが、ゼロ（空）に等しい場合があります。
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 MUST 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.
このビットは、何らかの形で断片化と再組み立てをサポートするプロトコルに対応するプロトコルディラパラメーターOctetでのみ設定する必要があります。TCPパケットは「断片化されたストリーム」とは見なされないため、TCPは適格ではないことに注意してください。
This bit MAY be set in more than one protocolDirParameters octet within a protocolDirTable INDEX, in the event an agent can count fragments at more than one protocol layer.
このビットは、エージェントが複数のプロトコル層でフラグメントをカウントできる場合に、プロトコルディル化可能なインデックス内で複数のプロトコルディラパラメーターオクテットで設定される場合があります。
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).
「トラックセッション（1）」ビットは、再マップされたセッションの一部であるフレーム（TFTPダウンロードセッションなど）がプローブによって正しくカウントされるかどうかを示します。このようなプロトコルの場合、プローブは通常、指定されたインターフェイスで受信したすべてのパケットを分析し、いくつかの状態情報を維持する必要があります（たとえば、TFTPの再マップされた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.
「トラックセッション」パラメーターのセマンティクスは、他のProtocoldirParametersの定義とは独立しているため、このパラメーターは他の法的パラメーター構成と組み合わせることができます。
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.
属性節は、プロトコルディリタイプの関連インスタンスにエンコードされたビット定義のリストです。ビット定義は、プロトコルディルタイプMIBオブジェクトの構文節で指定されています。
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
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.
The ATTRIBUTES clause MUST be present in all protocol-identifier macro declarations, but MAY be empty.
属性節は、すべてのプロトコル識別子マクロ宣言に存在する必要がありますが、空である場合があります。
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.
説明条項は、このマクロによって識別されたプロトコルのテキストの説明を提供します。子供がカバーするアイテム、住所形式、デコード、および参照条項の詳細を含めるべきではないことに注意してください。
The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations.
説明条項は、すべてのプロトコル識別子マクロ宣言に存在する必要があります。
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)
- 子プロトコルが親プロトコルラベルに関してどのように名前が付けられているかの詳細
The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause.
子供の条項は、「haschildren（0）」ビットが属性句に設定されているすべてのプロトコル識別子マクロ宣言に存在する必要があります。
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses.
アドレスフォーマット句は、アドレスをエンコードするときに使用されるオクテット弦形式の説明を提供します。
This clause MUST be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause.
この句は、「アドレス認識対応（1）」ビットが属性句に設定されているすべてのプロトコル識別子マクロ宣言に存在する必要があります。
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.
デコード句は、指定されたプロトコルのデコード手順の説明を提供します。実装者にとって有用なデコードヒントが含まれていますが、参照条項で引用されているドキュメントに情報を過剰に表現するべきではありません。必要なデコード情報の完全な説明が含まれている場合があります。
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）」ビットセット）の場合、これには、子どもの選択に使用されるフィールドのオフセットとタイプ情報、および子プロトコルの開始を決定する情報が含まれます。
For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses.
「アドレス認識対応」プロトコルの場合、これにはアドレスの生成に使用されるフィールドのオフセットとタイプ情報が含まれます。
The DECODING clause is optional, and MAY be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol.
デコード句はオプションであり、参照句に指定されたプロトコルの情報をデコードするポインターが含まれている場合は省略できます。
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.
子ども、住所形式、およびデコード条項は、割り当てられた番号ドキュメント[RFC1700]など、権威ある文書から現在取得される情報の量を制限する必要があります。情報の複製または言い換えは、権威ある文書と短時間かつ一致する必要があります。
The REFERENCE clause is optional, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols).
参照条項はオプションですが、プロトコル（特に標準プロトコル用）に権威ある参照が存在する場合は実装する必要があります。
The following evaluation is done after a protocolDirTable INDEX value has been converted into two OCTET STRINGs according to the INDEX encoding rules specified in the SMI [RFC1902].
以下の評価は、SMI [RFC1902]で指定されたインデックスエンコードルールに従って、プロトコルチャート可能なインデックス値が2つのオクテット文字列に変換された後に行われました。
Protocol-identifiers are evaluated left to right, starting with the protocolDirID, which length MUST be evenly divisible by four. The protocolDirParameters length MUST be exactly one quarter of the protocolDirID string length.
プロトコル識別子は、プロトコルディリドから始めて、左から右に評価されます。プロトコルディルパラメータの長さは、プロトコルディリド文字列の長さの正確な4分の1でなければなりません。
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 MUST NOT be skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can not exist.
プロトコル識別子解析は、プロトコルディリドのすべてのオクテットが使用されるまで、存在する必要があるベースレイヤー識別子から始まり、1つまたは複数の上層層識別子を継続します。レイヤーをスキップしてはならないため、「IP上のSNMP」や「Ether2上の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. (See section 4.1.1.2 for details.)
プロトコルカプセル化内の基本層でのワイルドカードは、現時点で唯一のサポートされている特別な機能です。（詳細については、セクション4.1.1.2を参照してください。）
After the protocol-identifier string (which is the value of protocolDirID) has been parsed, each octet of the protocol-parameters string is evaluated, and applied to the corresponding protocol layer.
プロトコル識別子文字列（プロトコルディリドの値）が解析された後、プロトコルパラメータ文字列の各オクテットが評価され、対応するプロトコル層に適用されます。
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' in the RMON Protocol Identifier Macros document [RFC2896]).
プロトコル識別子ラベルは、複数の値にマッピングできます。たとえば、「IP」は5つの異なる値にマッピングします。1つはサポートされています。（RMONプロトコル識別子マクロスドキュメント[RFC2896]の「L3プロトコル識別子」の下の「IP」セクションを参照してください）。
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」の各子は、少なくとも5つのプロトコル識別子にマッピングされ、1つは各カプセル化（例：ETHER2、IP Over LLCなど）です。
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings.
次のプロトコル識別子マクロを使用して、プロトコルディリドおよびプロトコルディルパラメーター文字列を構築できます。
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol.
識別子は、ベースインテネディファーを構築し、各カプセル化されたプロトコルに1つのレイヤーIDENTIFIERを追加することによりエンコードされます。
Refer to the RMON Protocol Identifier Macros document [RFC2896] for a listing of the non-base layer PI macros published by the working group. Note that other PI macro documents may exist, and it should be possible for an implementor to populate the protocolDirTable without the use of the PI Macro document [RFC2896].
ワーキンググループが発行した非基準層PIマクロのリストについては、RMONプロトコル識別子マクロスドキュメント[RFC2896]を参照してください。他のPIマクロドキュメントが存在する可能性があり、実装者がPIマクロドキュメント[RFC2896]を使用せずにプロトコルディル化可能なものに入力できることに注意してください。
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.
図2に示すように、ベース識別子は4オクテットとしてエンコードされます。
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
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」）は、指定された関数のオペランドです。使用していない場合は、オペランドをゼロに設定する必要があります。最後のオクテット「M」は、表4.2にある特定の基本層のカプセル化の列挙値です。4つのオクテットはすべて、ネットワークバイトオーダーでエンコードされています。
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
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
If the function ID field (1st octet) is equal to zero, 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フィールド（1st Octet）がゼロに等しい場合、「OP1」および「OP2」フィールド（2番目と3番目のオクテット）もゼロに等しくなければなりません。この特別な値は、残りのオクテットでエンコードされたプロトコル識別子に関数が適用されないことを示しています。識別子は、通常のプロトコルカプセル化を表します。
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 network layer protocol.
ワイルドカード関数（function-id = 1）は、単一のプロトコル値を使用して特定のネットワーク層プロトコルの潜在的に多くの基本層カプセルを示すことにより、カウンターを集約するために使用されます。このタイプのプロトコルディレントリーは、同じネットワークレイヤープロトコルのベース層カプセル化と一致します。
The 'op1' field (2nd octet) is not used and MUST be set to zero.
「OP1」フィールド（2番目のOctet）は使用されず、ゼロに設定する必要があります。
The 'op2' field (3rd octet) is not used and MUST be set to zero.
「OP2」フィールド（3番目のOctet）は使用されておらず、ゼロに設定する必要があります。
Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. The lowest possible base layer value SHOULD be chosen. So, if an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation. If not then an encapsulation over LLC should be used, if permitted. And so on for each of the defined base layers.
各ワイルドカードプロトコル識別子は、「ベースカプセル化」の観点から定義する必要があります。これは、相互運用性の目的でできるだけ「標準」でなければなりません。可能な限り低いベース層値を選択する必要があります。したがって、「Ether2」上のカプセル化が許可されている場合、これをベースカプセル化として使用する必要があります。そうでない場合は、許可されている場合は、LLCを介したカプセル化を使用する必要があります。定義された各ベースレイヤーについても同様です。
It should be noted that an agent does not have to support the non-wildcard protocol identifier over the same base layer. For instance a token ring only device would not normally support IP over the ether2 base layer. Nevertheless it should use the ether2 base layer for defining the wildcard IP encapsulation. The agent MAY also support counting some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RFC2021] 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.
エージェントは、同じ基本層で非ワイルドカードプロトコル識別子をサポートする必要がないことに注意する必要があります。たとえば、トークンリングのみのデバイスは、通常、Ether2ベースレイヤー上でIPをサポートしません。それにもかかわらず、WildCard IPカプセル化を定義するためにEther2ベースレイヤーを使用する必要があります。エージェントは、ワイルドカードカウントに加えて、同じプロトコルの個々のカプセルの一部またはすべてをカウントすることもサポートする場合があります。RMON-2 MIB [RFC2021]は、エージェントが同じプロトコルの複数のカプセルのカウンターを維持することを必要としないことに注意してください。これは、エージェントがどのプロトコルの組み合わせを、いつでもプロトコルディル化可能なプロトコルの組み合わせをどのように決定するかについての実装固有の問題です。
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.
基本層のプロトコルディルパラメータービットは推奨されていません。
The suggested value for the ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in the table 4.2 below. However, implementations are only required to use the appropriate integer identifier values.
ベースレイヤーのプロトコルディリッドフィールドの推奨値は、以下の表4.2の対応する「名前」フィールドによって与えられます。ただし、実装は、適切な整数識別子値を使用するためにのみ必要です。
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.
ほとんどの基本層プロトコルの場合、プロトコルディルタイプフィールドには、「ハスチャイルドレン（0）」および「アドレス認識対応（1）」属性に設定されたビットを含める必要があります。ただし、特別な「IANOASSIGNED」ベースレイヤーには、パラメーターまたは属性ビットセットが必要ありません。
By design, only 255 different base layer encapsulations are supported. There are five base encapsulation values defined at this time. Very few 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
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2 Encapsulation
-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.
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 high order byte and low order byte of the Ethernet-II type value.
このプロトコルの子供は[0.0.0.1]としてエンコードされます。[0.0.0.1]、「Ether2」のプロトコル識別子に続いて[0.0.A.B]が続き、「A」と「B」は高次バイトと低次バイトのネットワークバイト順序エンコーディングです。イーサネットIIタイプ値の。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
たとえば、：0.0.0.1.0.0.8.0のプロトコルディリドフラグメント値は、Ether2でカプセル化されたIPを定義します。
Children of ether2 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 1500 decimal indicate Ethernet-II frames; lower values indicate 802.3 encapsulation (see below)." REFERENCE "The authoritative list of Ether Type values is identified by the URL:
Ether2の子供は、「Ether2」と呼ばれ、その後、16進数の型フィールド値が続きます。上記の例は、eether2 0x0800 "アドレスフォーマット"イーサネットアドレスがネットワーク順序で6オクテットです。「1500を超えるタイプ値のみがイーサネット-IIフレームを示す」と宣言されます。低い値は802.3カプセル化を示します（以下を参照）。
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
-- LLC Encapsulation
-LLCカプセル化
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Logical Link Control (LLC) 802.2 protocol."
CHILDREN
"The LLC Source Service Access Point (SSAP) and Destination
Service Access Point (DSAP) 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).
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値です。たとえば、0.0.0.2.0.0.0.240のプロトコルディリドフラグメント値
defines NetBios over LLC.
Netbios over LLCを定義します。
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」と名付けられ、その後SAP値が16進数で挙げられます。したがって、上記の例には次の名前が付けられていました。LLC0xf0 "アドレス形式"アドレスは、ネットワーク順序で6オクテットのMACアドレスで構成されています。ソースルーティングビットは、存在する場合はアドレスから剥がす必要があります。「デコード」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 raw 802.3 encapsulations). For 802.5 there is no other link layer protocol.
LLCは、いくつかの異なるメディアに存在する可能性があります。802.3および802.5の場合、その存在は義務付けられています（ただし、Ether2およびRAW 802.3のカプセルを参照してください）。802.5の場合、他のリンクレイヤープロトコルはありません。
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 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
-- Encapsulation
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 Protocol Identifier field (PID) 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.
Haschildren（0）、DrastrecognitionCapable（1）}説明「サブネットワークアクセスプロトコル（SNAP）はLLCプロトコルの上に階層化されており、LLCに制限されたメディアでイーサネット-IIプロトコルを実行できるようにします。」「「スナップ」の子供はイーサネット-IIタイプの値によって識別されます。SNAPプロトコル識別子フィールド（PID）が適切な子を選択するために使用されます。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 high order byte and low order byte of the Ethernet-II type value.
「SNAP」の子供は[0.0.0.3]、「SNAP」のプロトコル識別子としてエンコードされ、その後[0.0.A.B]が続きます。ここで、「A」と「B」はイーサネットの高次バイトと低次バイトです。IIタイプ値。
For example, a protocolDirID-fragment value of: 0.0.0.3.0.0.8.0
たとえば、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"
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 Organizationally Unique Identifier (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 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation
- ベンダースナップオーバー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 have a
zero OUI value."
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. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order.
For example, a protocolDirID-fragment value of: 0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols over vsnap.
たとえば、：0.0.0.4.0.8.0.7のプロトコルディリドフラグメント値は、VSNAP上のApple固有のプロトコルセットを定義します。
Children are named as 'vsnap <OUI>', where the '<OUI>' field is represented as 3 octets in hexadecimal notation.
子供は「vsnap <oui>」と名付けられ、ここでは「<oui>」フィールドは16進表の3オクテットとして表されます。
So the above example would be named:
'vsnap 0x080007'"
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 and the SNAP
Protocol Identifier is not parsed."
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 }
-- IANA Assigned Protocols
-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).
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 'limited extensibility' feature of the protocolDirTable, and do not need special IANA assignments.
よく知られているプロトコルは、1つ以上のベンダー（SNMPなど）によって異なるポート番号に単純に再マッピングされる場合があります。これらのプロトコルは、プロトコルディル化可能な「限定的な拡張性」機能で識別でき、特別なIANAの割り当ては必要ありません。
A centrally located list of these enumerated protocols must be maintained by IANA to insure interoperability. (See section 2.3 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 'ianaAssigned' protocols.
これらの列挙されたプロトコルの中央に位置するリストは、相互運用性を保証するためにIANAによって維持する必要があります。（ドキュメントの更新手順の詳細については、セクション2.3を参照してください。）新しいリンク層のサポートが明示的に追加され、より良い方法で表現できないプロトコルのみが「ianasigned」プロトコルと見なされます。
IANA protocols are identified by the base-layer-selector value [ 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer value corresponding to the particular IANA protocol.
IANAプロトコルは、ベースレイヤーセレクター値[0.0.0.5]によって識別され、その後、特定のIANAプロトコルに対応する整数値の4オクテット[0.0.A.B]が続きます。
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 of this protocol are encoded as [ 0.0.0.5 ], the protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ] where 'a', 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
このプロトコルの子供は[0.0.0.5]、「IANASIGNED」のプロトコル識別子である[0.0.0.5]としてエンコードされ、その後[0.0.A.B]が続きます。特定のIANAが割り当てられたプロトコルの列挙値のバイト。
For example, a protocolDirID-fragment value of: 0.0.0.5.0.0.0.1
たとえば、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 numeric value of the particular IANA assigned protocol. The above example would be named:
子供の名前は「ianasigned」と呼ばれ、その後、特定のIANAが割り当てられたプロトコルの数値が続きます。上記の例には次の名前が付けられます。
'ianaAssigned 1' "
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 }
-- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a
-- proprietary way, by simple enumeration.
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
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, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
Encapsulation layers are positioned between the base layer and the network layer. It is an implementation-specific matter whether a probe exposes all such encapsulations in its RMON-2 Protocol Directory.
カプセル化層は、ベースレイヤーとネットワーク層の間に配置されます。プローブがRMON-2プロトコルディレクトリでそのようなすべてのカプセルを公開するかどうかは、実装固有の問題です。
RMON probes may encounter 'VLAN tagged' frames on monitored links. The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and [IEEE802.1D-1998], define an encapsulation layer inserted after the MAC layer and before the network layer. This section defines a PI macro which supports most (but not all) features of that encapsulation layer.
RMONプローブは、監視されたリンクで「VLANタグ付き」フレームに遭遇する場合があります。IEEE仮想LAN（VLAN）カプセル化標準[IEEE802.1Q]および[IEEE802.1D-1998]は、MACレイヤーの後にネットワーク層の前に挿入されたカプセル化層を定義します。このセクションでは、そのカプセル化層のほとんど（すべてではない）機能をサポートするPIマクロを定義します。
Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header. It is an implementation specific matter whether an RMON probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native (LLC-N) format, for the purpose of RMON collection.
最も注目すべきは、RMON PI Macro '802-1Q'は、VLANヘッダーのTCI部分でトークンリングカプセル化（TR-ENCAPS）ビットを公開しないことです。RMONコレクションを目的として、RMONプローブがLLC-Token Ring（LLC-TR）フォーマットされたフレームをLLC-Native（LLC-N）形式に変換するかどうかは、実装固有の問題です。
In order to support the Ethernet and LLC-N formats in the most efficient manner, and still maintain alignment with the RMON-2 ' collapsed' base layer approach (i.e., support for snap and vsnap), the children of 802dot1Q are encoded a little differently than the children of other base layer identifiers.
イーサネットとLLC-Nの形式を最も効率的な方法でサポートし、RMON-2の「崩壊した」基本層アプローチ（つまり、SNAPとVSNAPのサポート）とのアライメントを維持するために、802DOT1Qの子供は少しエンコードされます他の基本層識別子の子供とは異なります。
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not explicitly identified by this PI macro. Ethernet-encoded vs. SNAP-encoded TPID fields can be identified by the ifType of the data source for a particular RMON collection, since the SNAP-encoded format is used exclusively on Token Ring and FDDI media. Also, no information held in the TCI field (including the TR-encap bit) is identified in protocolDirID strings utilizing this PI macro."
TPIDフィールドの特定のエンコードは、このPIマクロによって明示的に識別されないことに注意してください。スナップエンコード形式はトークンリングとFDDIメディアでのみ使用されるため、特定のRMONコレクションのデータソースのIFTYPEによって、イーサネットエンコードとスナップエンコードTPIDフィールドが識別できます。また、TCIフィールド（TRエンコップビットを含む）に保持されている情報は、このPIマクロを利用したプロトコルディリド文字列で識別されません。」
CHILDREN "The first byte of the 4-byte child identifier is used to distinguish the particular base encoding that follows the 802.1Q header. The remaining three bytes are used exactly as defined by the indicated base layer encoding.
Children "4バイトチャイルド識別子の最初のバイトは、802.1Qヘッダーに続く特定のベースエンコーディングを区別するために使用されます。残りの3バイトは、指定された基本層エンコードで定義されたとおりに使用されます。
In order to simplify the child encoding for the most common cases, the 'ether2' and 'snap' base layers are combined into a single identifier, with a value of zero. The other base layers are encoded with values taken from Table 4.2.
最も一般的なケースの子エンコーディングを簡素化するために、「Ether2」と「Snap」ベースレイヤーは、ゼロの値で単一の識別子に結合されます。他の基本層は、表4.2から取得した値でエンコードされます。
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
The generic child layer-identifier format is shown below:
一般的な子層識別子形式を以下に示します。
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the Ethernet-II type value.
子供は[0.0.129.0]としてエンコードされます。「802-1Q」のプロトコル識別子[0.0.A.B]が続きます。ここで、「A」と「B」は、イーサネットIIタイプ値。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.0.0.8.0 defines IP, VLAN-encapsulated in ether2.
たとえば、0.0.0.0.1.0.0.129.0.0.0.8.0のプロトコルディリドフラグメント値は、Ether2でVLANがカプセル化されたIPを定義します。
Children of this format are named as '802-1Q' followed by the type field value in hexadecimal.
この形式の子供は、「802-1Q」と呼ばれ、その後、16進数の型フィールド値が続きます。
So the above example would be declared as: '802-1Q 0x0800'.
したがって、上記の例は次のように宣言されます： '802-1Q 0x0800'。
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier component for 802.1Q, followed by [ 2.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.1.0.0.129.0.2.0.0.240
子供は[0.0.129.0]としてエンコードされ、802.1Qのプロトコル識別子コンポーネント、続いて[2.0.0.a]が続きます。ここで、「A」は子プロトコルにマップするSAP値です。たとえば、0.0.0.1.0.0.129.0.2.0.0.240のプロトコルディリドフラグメント値
defines NetBios, VLAN-encapsulated over LLC.
LLCを介してVLANがカプセル化されたNetBiosを定義します。
Children are named as '802-1Q' followed by the SAP value in hexadecimal, with the leading octet set to the value 2.
子供の名前は「802-1Q」と名付けられ、その後に16進数でSAP値が続き、先頭のオクテットが値2に設定されます。
So the above example would have been named: '802-1Q 0x020000f0'
したがって、上記の例には名前が付けられていたでしょう： '802-1Q 0x020000F0'
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order.
子供は[0.0.129.0]、「802-1Q」のプロトコル識別子である[0.0.129.0]としてエンコードされ、その後[4.a.b.c]が続きます。注文。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of protocols, VLAN-encapsulated over vsnap.
たとえば、：0.0.0.0.1.0.0.129.0.4.8.0.7
Children are named as '802-1Q' followed by the <OUI> value, which is represented as 3 octets in hexadecimal notation, with a leading octet set to the value 4.
子供の名前は「802-1Q」と名付けられ、その後に<oui>値が続きます。これは、16進表の3オクテットとして表され、値4にセットされた先頭のオクテットが設定されています。
So the above example would be named: '802-1Q 0x04080007'.
したがって、上記の例には、 '802-1q 0x04080007'という名前が付けられます。
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
子供は[0.0.129.0]、「802-1Q」のプロトコル識別子である[0.0.129.0]としてエンコードされ、その後[5.0.A.B]が続きます。ここで、「A」と「B」は高次のバイトと低オーダーバイトのネットワークバイト順序エンコーディングです。特定のIANAが割り当てられたプロトコルの列挙値の。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.5.0.0.0.1
たとえば、0.0.0.1.0.0.129.0.5.0.0.1のプロトコルディリドフラグメント値
defines the IPX protocol, VLAN-encapsulated directly in 802.3
802.3で直接VLANでカプセル化されたIPXプロトコルを定義します
Children are named '802-1Q' followed by the numeric value of the particular IANA assigned protocol, with a leading octet set to the value of 5.
子供の名前は「802-1Q」に続いて、特定のIANAが割り当てられたプロトコルの数値を使用し、5の値にセットされています。
Children are named '802-1Q' followed by the hexadecimal encoding of the child identifier. The above example would be named:
子供の名前は「802-1Q」に続いて、子どもの識別子の16進コード化されています。上記の例には次の名前が付けられます。
'802-1Q 0x05000001'. "
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity
}
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat."
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。」
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
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.
Anil Singhal Frontier Software Development、Inc。
Jeanne Haney Bay Networks
Jeanne Haney Bay Networks
Dan Hansen Network General Corp.
Dan Hansen Network General Corp.
Special thanks are in order to the following people for writing RMON PI macro compilers, and improving the specification of the PI macro language:
RMON PIマクロコンパイラを作成し、PIマクロ言語の仕様を改善してくれたことに感謝します。
David Perkins DeskTalk Systems, Inc.
David Perkins Desktalk Systems、Inc。
Skip Koppenhaver Technically Elite, Inc.
Skip Koppenhaver Technically Elite、Inc。
[AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995.
[AF-LANE-0021.000] LANエミュレーションサブワーキンググループ、B。エリントン、「ATM上のLANエミュレーション - バージョン1.0」、AF-LANE-0021.000、ATMフォーラム、IBM、1995年1月。
[AF-NM-TEST-0080.000] Network Management Sub-working Group, Test Sub-working Group, A. Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997.
[AF-NM-TEST-0080.000]ネットワーク管理サブワーキンググループ、テストサブワーキンググループ、A。ビアマン、「ATMネットワーク用のリモートモニタリングMIB拡張」、AF-NM-Test-0080.000、ATMフォーラム、シスコシステム、Cisco Systems、1997年2月。
[IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE Computer Society, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specification -- Part 3: Media Access Control (MAC) Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Electrical and Electronics Engineers, Inc., May 1998.
[IEEE802.1D-1998] IEEE Computer SocietyのLAN Man Standards委員会、「情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ」、ISO/IEC最終DIS 15802-3（IEEE P802.1D/D17）Institute of Electrical and Electronics Engineers、Inc.、1998年5月。
[IEEE802.1Q] LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D11, Institute of Electrical and Electronics Engineers, Inc., July 1998.
[IEEE802.1Q] IEEE Computer SocietyのLAN Man Standards Committee、「ローカルおよびメトロポリタンエリアネットワークのIEEE基準：仮想ブリッジ型ローカルエリアネットワーク」、ドラフト標準P802.1Q/D11、Institute of Electric and Electronics Engineers、Inc。1998年7月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1155] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol」、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] Rose、M。およびK. McCloghrie、「Concise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するためのトラップを定義するための条約」、RFC 1215、1991年3月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J。、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「コミュニティベースのSNMPV2の紹介」、RFC 1901、1996年1月。
[RFC1902] 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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2の管理情報の構造」、RFC 1902、1996年1月。
[RFC1903] 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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「シンプルネットワーク管理プロトコル（SNMPV2）のバージョン2のテキストコンベンション」、RFC 1903、1996年1月。
[RFC1904] 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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2の適合ステートメント」、RFC 1904、1996年1月。
[RFC1905] 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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2のプロトコル操作」、RFC 1905、1996年1月。
[RFC1906] 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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2の輸送マッピング」、RFC 1906、1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
[RFC2021] Waldbusser、S。、「リモートネットワーク監視MIB（RMON-2）」、RFC 2021、1997年1月。
[RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997.
[RFC2074] Bierman、A。およびR. Iddon、「リモートネットワーク監視MIBプロトコル識別子」、RFC 2074、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, November 1997.
[RFC2233] McCloghrie、K。およびF. Kastenholz、「SMIV2を使用したインターフェースグループMIB」、RFC 2233、1997年11月。
[RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
[RFC2271] Harrington、D.、Presuhn、R。およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2271、1998年1月。
[RFC2272] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998.
[RFC2272] Case、J.、Harrington D.、Presuhn R.およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、RFC 2272、1998年1月。
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998.
[RFC2273] Levi、D.、Meyer、P。and B. Stewart、「SNMPV3アプリケーション」、RFC 2273、1998年1月。
[RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
[RFC2274] Blumenthal、U.およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、RFC 2274、1998年1月。
[RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998.
[RFC2275] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、RFC 2275、1998年1月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[RFC2570] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン3の紹介」、RFC 2570、1999年4月。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[RFC2571] Harrington、D.、Presuhn、R。およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、1999年4月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572] Case、J.、Harrington D.、Presuhn R.およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、RFC 2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[RFC2573] Levi、D.、Meyer、P。and B. Stewart、「SNMPV3 Applications」、RFC 2573、1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574] Blumenthal、U.およびB. Wijnen、「シンプルネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、RFC 2574、1999年4月。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、1999年4月、RFC 2575。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「管理情報の構造バージョン2（SMIV2）、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。、およびS. Waldbusser、「Smiv2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros", RFC 2896, August 2000.
[RFC2896] Bierman、A.、Bucci、C。およびR. Iddon、「リモートネットワーク監視MIBプロトコル識別子マクロ」、RFC 2896、2000年8月。
The protocols identified in this specification are almost entirely defined in external documents. In some rare cases, an arbitrary Protocol Identifier assignment must be made in order to support a particular protocol in the RMON-2 protocolDirTable. Protocol Identifier macros for such protocols will be defined under the ' ianaAssigned' base layer (see sections 3. and 4.2).
この仕様で特定されたプロトコルは、ほぼ完全に外部ドキュメントで定義されています。まれな場合には、RMON-2プロトコルディル化可能な特定のプロトコルをサポートするために、任意のプロトコル識別子割り当てを行う必要があります。このようなプロトコルのプロトコル識別子マクロは、「IANOASSIGNED」ベースレイヤーの下で定義されます（セクション3.および4.2を参照）。
At this time, only one protocol is defined under the ianaAssigned base layer, called 'ipxOverRaw8023' (see section 4.2).
現時点では、「IPXOVERRAW8023」と呼ばれるIANAが割り当てられた基本層の下で1つのプロトコルのみが定義されています（セクション4.2を参照）。
This document discusses the syntax and semantics of textual descriptions of networking protocols, not the definition of any networking behavior. As such, no security considerations are raised by this memo.
このドキュメントでは、ネットワーキング動作の定義ではなく、ネットワークプロトコルのテキスト説明の構文とセマンティクスについて説明します。そのため、このメモによってセキュリティ上の考慮事項は提起されていません。
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Andy Bierman Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Chris Bucci Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Robin Iddon c/o 3Com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh, EH1 1NE, UK
Robin Iddon C/O 3com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh、EH1 1NE、英国
Phone: +44 131.558.3888 EMail: None
電話：44 131.558.3888メール：なし
Appendix A: Changes since RFC 2074
付録A：RFC 2074以降の変更
The differences between RFC 2074 and this document are:
RFC 2074とこのドキュメントの違いは次のとおりです。
- RFC 2074 has been split into a reference document (this document) on the standards track and an informational document [RFC2896], in order to remove most protocol identifier macros out of the standards track document. - Administrative updates; added an author, added copyrights, updated SNMP framework boilerplate; - Updated overview section. - Section 2.1 MUST, SHOULD text added per template - Section 2.1 added some new terms - parent protocol - child protocol - protocol encapsulation tree - Added section 2.3 about splitting into 2 documents:
- RFC 2074は、ほとんどのプロトコル識別子マクロを標準トラックドキュメントから削除するために、標準トラックと情報ドキュメント[RFC2896]の参照ドキュメント（このドキュメント）に分割されています。 - 管理の更新。著者を追加し、著作権を追加し、SNMPフレームワークボイラープレートを更新しました。 - 更新された概要セクション。 - セクション2.1は、テンプレートごとに追加される必要があります - セクション2.1はいくつかの新しい用語を追加しました - 親プロトコル - 子プロトコル - プロトコルカプセル化ツリー - 2つのドキュメントへの分割に関するセクション2.3が追加されました。
"Relationship to the RMON Protocol Identifier Macros Document" - Added section 2.4 "Relationship to the ATM-RMON MIB" - rewrote section 3.2 "Protocol Identifier Macro Format" But no semantic changes were made; The PI macro syntax is now specified in greater detail using BNF notation. - Section 3.2.3.1 "Mapping of the 'countsFragments(0)' BIT" - this section was clarified to allow multiple protocolDirParameters octets in a given PI string to set the 'countsFragments' bit. The RFC version says just one octet can set this BIT. It is a useful feature to identify fragmentation at multiple layers, and most RMON-2 agents were already doing this, so the WG agreed to this clarification. - Added section 4.3 "Encapsualtion Layers" - This document ends after the base layer encapsulation definitions (through RFC 2074, section 5.2) - Added Intellectual Property section - Moved RFC 2074 section 5.3 "L3: Children of Base Protocol Identifiers" through the end of RFC 2074, to the PI Reference [RFC2896] document, in which many new protocol identifier macros were added for application protocols and non-IP protocol stacks. - Acknowledgements section has been updated
「RMONプロトコル識別子マクロドキュメントとの関係」 - セクション2.4「ATM -RMON MIBへの関係」 - セクション3.2「プロトコル識別子マクロ形式」を書き直しましたが、セマンティックの変更は行われませんでした。PIマクロ構文は、BNF表記を使用して詳細に指定されています。 - セクション3.2.3.1「「countsfragments（0） 'bit」のマッピング - このセクションは、特定のPIストリング内の複数のプロトコルディルパラメータオクテットが「countsfragments」ビットを設定できるようにするために明確にされました。RFCバージョンでは、1つのオクテットがこのビットを設定できると言っています。これは、複数の層で断片化を識別するのに便利な機能であり、ほとんどのRMON-2エージェントがすでにこれを行っていたため、WGはこの明確化に同意しました。 - セクション4.3の「カプセルティオンレイヤー」を追加しました - このドキュメントは、基本層のカプセル化定義（RFC 2074、セクション5.2を介して）の後に終了します。RFC 2074、PIリファレンス[RFC2896]ドキュメントに、アプリケーションプロトコルおよび非IPプロトコルスタックのために多くの新しいプロトコル識別子マクロが追加されました。 - 謝辞セクションが更新されました
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。