RFC2895 日本語訳
2895 Remote Network Monitoring MIB Protocol Identifier Reference. A.Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=88094 bytes) (Obsoletes RFC2074) (Updated by RFC3395) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Biermanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2895 C.ブッチは以下を時代遅れにします。 2074年のシスコシステムズInc.カテゴリ: 標準化過程R.Iddon 3Com Inc.2000年8月
Remote Network Monitoring MIB Protocol Identifier Reference
リモートネットワーク監視MIBプロトコル識別子参照
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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(遠く離れたNetwork Monitoring Management Information基地)[RFC2021]で見つけられたprotocolDirTableのためにINDEX値をコード化することにおける使用のために。 また、標準プロトコルディレクトリ基層識別子のための定義は含まれています。
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プロトコルIdentifiers Document[RFC2074]の最初のバージョンは標準化過程のReference部分(このドキュメント)、およびInformationalドキュメントに分けられました。 RMONプロトコルIdentifier Macrosドキュメント[RFC2896]は現在、その仕様の非標準の部分を含みます。
This document obsoletes RFC 2074.
このドキュメントはRFC2074を時代遅れにします。
Bierman, et al. Standards Track [Page 1] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[1ページ]。
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
1 SNMPネットワークマネージメントフレームワーク… 3 2概要… 3 2.1の用語… 4 2.2 リモートとの関係はモニターしているMIBをネットワークでつなぎます… 6 2.3 RMONプロトコル識別子マクロとの関係は気圧-RMON MIBとの.62.4関係を記録します… 7 2.4 .1 集合を移植してください… 7 2.4 .2 カプセル化マッピング… 7 2.4 .3 RMON-2収集における気圧トラフィックを数えます… 8 他のMIBsとの2.5関係… 9 3は識別子コード化について議定書の中で述べます… 9 3.1 ProtocolDirTableは形式の例に索引をつけます… 11 3.2 識別子マクロ形式について議定書の中で述べてください… 12 3.2 .1 語彙コンベンション… 12 3.2 構文記述のための.2記法… 13 3.2 パイ言語のための.3文法… 13 3.2 プロトコル名に関する.4マッピング… 15 3.2 .5マッピング、異形、-、節… 16 3.2 パラメタ節に関する.6マッピング… 17 3.2 .6 'countsFragments(0)'ビットの.1マッピング… 18 3.2 .6 'tracksSessions(1)'ビットの.2マッピング… 18 3.2 属性節に関する.7マッピング… 18 3.2 記述節に関する.8マッピング… 19 3.2 子供節に関する.9マッピング… 19 3.2 アドレス形式節に関する.10マッピング… 20 3.2 解読節に関する.11マッピング… 20 3.2 参照節に関する.12マッピング… 20 3.3 ProtocolDirTableのインデックスを評価します… 21 4 層のプロトコル識別子マクロを基礎づけてください… 22 4.1 識別子コード化を基礎づけてください… 22 4.1 .1 識別子機能について議定書の中で述べてください… 22 4.1 .1 .1 機�%%BODY%%: なにも… 23 4.1 .1 .2 機能1: ワイルドカード機能について議定書の中で述べてください… 23 4.2 層のプロトコル識別子を基礎づけてください… 24 4.3 カプセル化は層にされます… 31 4.3 .1 IEEE802.1Q… 31 5知的所有権… 34 6つの承認… 35 7つの参照箇所… 35 8 IANA問題… 39 9 セキュリティ問題… 39 10人の作者のアドレス… 40 付録A… 41 11の完全な著作権宣言文… 42
Bierman, et al. Standards Track [Page 2] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[2ページ]。
1. The SNMP Network Management Framework
1. SNMPネットワークマネージメントフレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[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 オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]、およびRFC1215[RFC1215]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[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メッセージプロトコルの最初のバージョンは、STD15、RFC1157[RFC1157]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[RFC1901]とRFC1906[RFC1906]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]でSNMPv3と呼ばれて、説明されます。
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形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[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 RFC2573[RFC2573]で説明された1セットの基礎的応用と視点ベースのアクセス管理機構はRFC2575で[RFC2575]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
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.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo does not specify a MIB module.
このメモはMIBモジュールを指定しません。
2. Overview
2. 概要
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
[RFC2021]が階層的で使用するRMON-2 MIBは、protocolDirTableで個々のプロトコルカプセル化をグローバルに特定するためにOCTET STRINGsをフォーマットしました。
Bierman, et al. Standards Track [Page 3] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[3ページ]。
This guide contains algorithms and the authoritative set of base layer protocol identifier macros, for use within INDEX values in the protocolDirTable.
このガイドはアルゴリズムと正式のセットの基層プロトコル識別子マクロを含みます、protocolDirTableのINDEX値の中の使用のために。
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プロトコルIdentifiersドキュメントの前半を取り替えることを意図します。 [RFC2074。]
2.1. Terms
2.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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.)
層識別子: 特定のプロトコルカプセル化層か副層を表す八重奏ストリング断片。 断片はまさにネットワークバイトオーダーでコード化された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]で時々使用されることに注意してください。 このような場合には、プロトコル識別子ストリングは最高の層にちなんで命名されます。 また、命名されたプロトコルはそのプロトコルのどんなカプセル化についても言及するかもしれません。
Bierman, et al. Standards Track [Page 4] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[4ページ]。
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.
プロトコル識別子ストリング: 符号化規則で本書では指定されるように特定のプロトコルカプセル化を表す八重奏ストリング。 protocolDirIDが反対するようにこのストリングはRMON-2 MIB[RFC2021]で特定されます。 プロトコル識別子ストリングが1で構成されるか、または、より多くの層識別子が左から右まで読みます。 最も左の層識別子は基層カプセル化を指定します。 右へのそれぞれの層識別子は子供層のプロトコルカプセル化を指定します。
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].
プロトコル識別子マクロ: また、PIマクロと呼ばれます。 マクロのような原文の構造物は以前はよく特定のネットワーク・プロトコルについて説明していました。 RMON使用に、重要なプロトコル属性だけが記録されます。 'マクロ'という用語が歴史的であり、PIマクロが本当のマクロでないことに注意してください、そして、それらはASN.1マクロではありません。 RMONプロトコルIdentifier Macrosドキュメント[RFC2896]で現在のセットの発行されたRMON PIマクロを見つけることができます。
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]の中の使用にちなんで命名します。 - プロトコルがどうコード化されるかを八重奏ストリングに説明します。 - 子供プロトコルがどう特定されて(適切であるなら)、コード化されるかを八重奏ストリングに説明します。 - どのprotocolDirParametersがプロトコルのために許容されているかを説明します。 - 関連protocolDirTypeオブジェクトがプロトコルのためにどうコード化されるかを説明します。 - 正式のドキュメンテーションのプロトコルの参照を提供します。
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.
プロトコル異形識別子マクロ: また、PI-異形マクロと呼ばれます。 プロトコルを最もネットワークでつなぐような決定論、および(通常)階層構造と同一視できない特定のプロトコル層について説明するのに使用される特別な種類の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-異形マクロとPI-マクロが1セットのシンタックス・ルールで定義されることに注意してください(セクション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
PI-異形マクロと同一視されたプロトコルは実際にprotocolDirTableに存在するかもしれないよく知られているカプセル化の異形です。 これは、'適切なネットワークトラフィック'(例えば、それらを運ぶパケット)の試験で実際に特定できないプロトコルを特定するのに必要であるプロトコルが割り当てられたIANAを記録するのに使用されます。 他のすべてのプロトコル、(試験でどれを特定できるか、適切
Bierman, et al. Standards Track [Page 5] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[5ページ]。
network traffic) SHOULD be documented using the protocol-
identifier macro. (See section 3.2 for details.)
ネットワークトラフィック) SHOULD、プロトコル識別子マクロを使用することで、記録されてください。 (詳細に関してセクション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つのプロトコルパラメタを含みます)。 protocolDirParametersが反対するようにこのストリングはRMON-2 MIB[RFC2021]で特定されます。 (詳細に関してセクション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値に変換された組を結びます、RFC1902[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.
カプセル化木について議定書の中で述べてください: プロトコルカプセル化を逆ツリーに組織化できます。 根のノードはベースカプセル化です。 もしあれば木のノードの子供ノードは子供プロトコルのカプセル化です。
2.2. Relationship to the Remote Network Monitoring MIB
2.2. リモートネットワーク監視MIBとの関係
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オブジェクトのprotocolDirIDとprotocolDirParametersのために符号化規則を特定することを意図します。 新しいプロトコルDistributionのそれらなどのRMON-2テーブル(Host、およびマトリクスグループ)は、目的を数えるためにプロトコルを特定するのに、完全なprotocolDirTable INDEXストリングよりむしろ地方のINTEGER INDEX(protocolDirLocalIndex)を使用します。 protocolDirTableだけがストリングが本書では説明したprotocolDirIDとprotocolDirParametersを使用します。
This document is intentionally separated from the RMON-2 MIB objects [RFC2021] to allow updates to this document without any republication of MIB objects.
このドキュメントは、MIBオブジェクトの少しも再刊なしでこのドキュメントにアップデートを許すために故意にRMON-2 MIBオブジェクト[RFC2021]と切り離されます。
Bierman, et al. Standards Track [Page 6] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[6ページ]。
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.
このドキュメントはprotocolDirTableの自動発見と自動人口について議論しません。 この機能性はRMON規格によって明らかに定義されません。 エージェントSHOULDは意図しているアプリケーションがよる'おもしろい'プロトコルでディレクトリに居住します。
2.3. Relationship to the RMON Protocol Identifier Macros Document
2.3. RMONプロトコル識別子マクロドキュメントとの関係
The original RMON Protocol Identifiers document [RFC2074] contains the protocol directory reference material, as well as many examples of protocol identifier macros.
オリジナルのRMONプロトコルIdentifiersドキュメント[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プロトコルIdentifier Macrosドキュメント[RFC2896]と呼ばれる別々のドキュメントに動かされました。 これで、標準のテキスト(このドキュメント)はRMON-2 MIB[RFC2021]と共に標準化過程の上を進むでしょう、PIマクロの収集がInformational 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メーリングリストへの)から提出されたプロトコルIdentifierマクロは、PI Macrosドキュメントのその後のバージョンに集められて、RMONMIBワーキンググループによって上映されて、追加されるでしょう(承認されるなら)。
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ワーキンググループメーリングリストメッセージアーカイブファイルのメールwww.ietf.org/アーカイブ/働くグループ/rmonmib/電流/maillist.htmに集められるでしょう。
2.4. Relationship to the ATM-RMON MIB
2.4. 気圧-RMON MIBとの関係
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 Forumは「気圧ネットワークに、リモートなモニターしているMIB拡張子」(ATM-RMON MIB)[AFニューメキシコTEST-0080.000]を標準化しました。(それは、NSAPのアドレスベース(ATM Adaption Layer5、AAL-5)のセルトラフィックにRMONのような統計、ホスト、マトリクス、およびmatrixTopN能力を供給します)。
2.4.1. Port Aggregation
2.4.1. ポート集合
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'がパケットベースの収集で使用されるように同じレベルのポート集合を提供するために構成されるだけであるかどうかにおいて、可能です。 これは、ATM-RMON'portSelectGroup'が伝統的なRMON dataSourcesの場合に単一のポートを含むのを必要とするでしょう。
Bierman, et al. Standards Track [Page 7] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[7ページ]。
2.4.2. Encapsulation Mappings
2.4.2. カプセル化マッピング
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ドキュメントは「気圧適合層5インチ[RFC1483]、または気圧フォーラム「気圧でのLANエミュレーション」(レーン)[AFレーン0021.000]の上のMultiprotocolカプセル化」の明白なPIマクロサポートを含んでいません。 代わりに、徹底的調査は本書では定義された基層(すなわち、llc、スナップ、またはvsnap)の1つにATMカプセル化に'合わなければなりません'、生データがエージェント(例えば、VC- muxing、対LLC-muxingかブリッジされるに対して発送された形式)によってどう得られるかにかかわらず。 特定の基層を特定して、解読することに関する詳細に関してセクション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)
RFC1483dataSource ifTypes: - aal5(49)
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
車線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.
これらのdataSourcesはInterfaces MIB[RFC2233]からifStackTableの実装を必要とします。 いくつかの実装が'気圧(37)'のifTypeを示すdataSource値を使用するのが(ifStackTableがサポートされないので)、可能である、しかしながら、これはRMONMIB WGで強くがっかりしています。
2.4.3. Counting ATM Traffic in RMON-2 Collections
2.4.3. RMON-2収集における気圧トラフィックを数えます。
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 Application Layer(AL)とNetwork Layer(NL)(ホスト/マトリクス/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')に、'フレーム・サイズ'として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のベースのトラフィックのパケット捕獲に関連する問題を扱っていません。 したがって、そっと歩くか否かに関係なく、八重奏(すなわち、802.3か802.5トラフィックであるとブリッジされたRFC1483VC-muxedかレーントラフィック)がRMON-1'captureBufferPacketData'MIBオブジェクトに表されるのは、実装特有の問題です。 通常、捕らわれているフレームの最初の八重奏は送付先MACアドレス(DA)の最初の八重奏です。
Bierman, et al. Standards Track [Page 8] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[8ページ]。
2.5. Relationship to Other MIBs
2.5. 他のMIBsとの関係
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プロトコルIdentifiers Referenceドキュメントは使用のためにRMON MIBの中のprotocolDirTableと共に意図します。 それは、いかなる他のMIBにも関連しない、またいかなる他のMIBとの使用のためにも意図していません。
3. Protocol Identifier Encoding
3. プロトコル識別子コード化
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable- length string is converted to an OBJECT IDENTIFIER fragment, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index fragments are simply concatenated. (Refer to figures 1a - 1d below for more detail.)
protocolDirTableは2OCTET STRINGs、protocolDirID、およびprotocolDirParametersによって索引をつけられます。 テーブルインデックスをコード化するために、それぞれの可変長さのストリングはOBJECT IDENTIFIER断片に変換されます、RFC1902[RFC1902]のセクション7.7の符号化規則によると。 そして、インデックス断片は単に連結されます。 (数字の1aを参照してください--その他の詳細のための以下の1d)
The first OCTET STRING (protocolDirID) is composed of one or more 4- octet "layer-identifiers". The entire string uniquely identifies a particular 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.
最初のOCTET STRING(protocolDirID)は1 4八重奏「層識別子」で構成されます。 全体のストリングはプロトコルカプセル化木で唯一特定のノードを特定します。 第2OCTET STRING、対応する数の1八重奏のプロトコル特有のパラメタ、各4八重奏あたり1つを含む(protocolDirParameters)が最初のストリングの識別子を層にします。
A protocol layer is normally identified by a single 32-bit value. Each layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of the 32-bit value in network byte order. If a particular protocol layer cannot be encoded into 32 bits, then it must be defined as an 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
通常、プロトコル層はただ一つの32ビットの値によって特定されます。 'それぞれの層識別子は4つのサブコンポーネント[a.b.c.d]としてProtocolDirID OCTET STRING INDEXでコード化されます、どこ'a'--、'ネットワークバイトオーダーにおける、32ビットの価値の各バイトを表してくださいか。 特定のプロトコル層を32ビットにコード化できないなら、'ianaAssigned'プロトコルとそれを定義しなければなりません(プロトコルが割り当てられたIANAに関する詳細に関して以下を見てください)。
The following figures show the differences between the OBJECT IDENTIFIER and OCTET STRING encoding of the protocol identifier string.
以下の数字には、プロトコル識別子ストリングのOBJECT IDENTIFIERとOCTET STRINGコード化の差異があります。
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
図1a protocolDirTableインデックス形式-----------------------------
+---+--------------------------+---+---------------+ | c ! | c ! protocolDir | | n ! protocolDirID | n ! Parameters | | t ! | t ! | +---+--------------------------+---+---------------+
+---+--------------------------+---+---------------+ | c!| c!protocolDir| | n! protocolDirID| n!Parameters| | t!| t!| +---+--------------------------+---+---------------+
Bierman, et al. Standards Track [Page 9] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[9ページ]。
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
図1b protocolDirTable八重奏記号列の書式------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirID+----------------------------------------+ | | | 4*N八重奏| | | +----------------------------------------+
protocolDirParameters +----------+ | | | N octets | | | +----------+
protocolDirParameters+----------+ | | | N八重奏| | | +----------+
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
-------------------------------------
図1c protocolDirTableインデックス形式の例-------------------------------------
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
protocolDirID protocolDirParameters+---+--------+--------+--------+--------+---+---+---+---+---+ | c| proto| proto| proto| proto| c|平価|平価|平価|平価| | n| ベース| L(B+1)| L(B+2)| L(B+3)| n|Ba| L3| L4| L5| | t|(+ 旗)| L3| L4| L5| t|se| | | | +---+--------+--------+--------+--------+---+---+---+---+---+ subOID| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | カウント
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'.
protocolDirTable INDEXでコード化されると、長さのサブコンポーネントはそれぞれの2個のストリングに先行しなければなりません。 'この例では、Nは'4'と等しく、最初の'cnt'分野は16年を評価してください、'2番目の'cnt'分野は値を含んでいるだろう'という4を含んでいるでしょう'。
Bierman, et al. Standards Track [Page 10] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[10ページ]。
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
図1d protocolDirTable八重奏記号列の書式の例--------------------------------------------
protocolDirID +--------+--------+--------+--------+ | proto | proto | proto | proto | | base | L3 | L4 | L5 | | | | | | +--------+--------+--------+--------+ octet | 4 | 4 | 4 | 4 | count
protocolDirID+--------+--------+--------+--------+ | proto| proto| proto| proto| | ベース| L3| L4| L5| | | | | | +--------+--------+--------+--------+ 八重奏| 4 | 4 | 4 | 4 | カウント
protocolDirParameters +---+---+---+---+ |par|par|par|par| |ba-| L3| L4| L5| |se | | | | +---+---+---+---+ octet | 1 | 1 | 1 | 1 | count
protocolDirParameters+---+---+---+---+ |平価|平価|平価|平価| |Ba| L3| L4| L5| |se| | | | +---+---+---+---+ 八重奏| 1 | 1 | 1 | 1 | カウント
Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 3.5 of RFC 1902 [RFC1902].
この例は、4が実際にはプロトコルをカプセル化したのを示しますが、どんな非ゼロ番号の層識別子も、現在であって、単にOBJECT IDENTIFIER長さの制限で理論的に限られるかもしれません、RFC1902[RFC1902]のセクション3.5で指定されるように。
3.1. ProtocolDirTable INDEX Format Examples
3.1. ProtocolDirTableインデックス形式の例
The following PI identifier fragments are examples of some fully encoded protocolDirTable INDEX values for various encapsulations.
以下のPI識別子断片は様々なカプセル化のためのいくつかの完全にコード化されたprotocolDirTable INDEX値に関する例です。
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- HTTP。 断片がIPとether2.ip.tcp.www-http=16.0.0.0より上で.1を数えた、.0、.0、.8、.0、.0、.0、.0、.6、.0、.0、.0、.80、.4、.0、.1、.0、.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNAP snap.ip.udp.snmp=16.0.0の上のUDP/IPの上のSNMP、.0、.3、.0、.0、.8、.0、.0、.0、.0、.17、.0、.0、.0、.161、.4、.0、.0、.0、.0
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNAP snap.ipx.snmp=12.0.0の上のIPXの上のSNMP、.0、.3、.0、.0、.129、.55、.0、.0、.144、.15、.3、.0、.0、.0
-- SNMP over IPX over raw8023
ianaAssigned.ipxOverRaw8023.snmp =
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- raw8023 ianaAssigned.ipxOverRaw8023.snmp=12.0.0の上のIPXの上のSNMP、.0、.5、.0、.0、.0、.1、.0、.0、.144、.15、.3、.0、.0、.0
Bierman, et al. Standards Track [Page 11] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[11ページ]。
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.0.0.224.2.0.0
-- LLC llc.ipx=8.0.0の上のIPX、.0、.2、.0、.0、.0、.224、.2、.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
-- いずれも上のUDP/IPの上のSNMPが層ether2.ip.udp.snmp16.1.0の.0をリンクする、.1、.0、.0、.8、.0、.0、.0、.0、.17、.0、.0、.0、.161、.4、.0、.0、.0、.0
-- IP over any link layer; base encoding is IP over ether2
ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- どんなリンクレイヤの上のIP。 ベース、コード化して、ether2 ether2.ip8.1の上のIPが.0である、.0、.1、.0、.0、.8、.0、.2、.0、.0
-- AppleTalk Phase 2 over ether2
ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- ether2 ether2.atalk8.0の上のAppleTalk Phase2、.0、.0、.1、.0、.0、.128、.155、.2、.0、.0
-- 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.atalk12.0の上のAppleTalk Phase2、.0、.0、.4、.0、.8、.0、.7、.0、.0、.128、.155、.3、.0、.0、.0
3.2. Protocol Identifier Macro Format
3.2. プロトコル識別子マクロ形式
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'コンポーネントが存在しているなら、マクロはプロトコルの代わりにプロトコル異形を表します。 この節は現在、'ianaAssigned'基層の下で列挙されたプロトコルが割り当てられたIANAにだけ使用されます。 VariantOfPartの部品はプロトコルが割り当てられたIANAのために存在していなければなりません。
3.2.1. Lexical Conventions
3.2.1. 語彙コンベンション
The PI language defines the following keywords:
PI言語は以下のキーワードを定義します:
ADDRESS-FORMAT
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
記述パラメタプロトコル識別子参照を解読するアドレス形式属性子供、異形、-
Bierman, et al. Standards Track [Page 12] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[12ページ]。
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
左の巻き毛の支柱は巻き毛の支柱(左括弧)右括弧、コンマを正します:、:= 2コロンと等号--2つのダッシュ
3.2.2. Notation for Syntax Descriptions
3.2.2. 構文記述のための記法
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'
* 縦棒、(|、)、項目の選択、例えば、'数'を示すために、使用されます。| 'hstr'
* Ellipsis are used to indicate that the previous item may be
repeated one or more times, for example <parm>...
* 省略は前の項目が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'
* 同輩キャラクタ(=)が意味するのにおいて使用されている、「定義される」、例えば、'<protoName>はpnameと等しいです'。
3.2.3. Grammar for the PI Language
3.2.3. パイ言語のための文法
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:
以下は、文法の「端末」であり、MIBモジュール言語からの同じ字句要素と同じです、hstrとpnameを除いて:
<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"
<lc>は“a"と等しいです。| 「b」| 「c」| ... | 「z」<uc>は「A」と等しいです。| 「B」| 「C」| ... | 「Z」<手紙>=<lc>。| <uc><ケタ>=「0インチ」| "1" | ... | 「9インチの<hdigit>は<ケタ>と等しいです」| "a"| 「A」| 「b」| 「B」| ... | 「f」| 「F」
Bierman, et al. Standards Track [Page 13] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[13ページ]。
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<lcname>は<lc>[<の最もlcrestな>]の<の最もlcrestな>=(<手紙>| <ケタ>| 「-」)と等しいです。[<の最もlcrestな>]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<pname>は<の最もpnrestな>=(<手紙>| <ケタ>| 「-」|"_"|「*」)と等しいです(<手紙>| <ケタ>)[<の最もpnrestな>]。[<の最もpnrestな>]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<番号>は4g-1の最大12月の価値への<ケタ>[<番号>]と等しいです。
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<hstr>は<hdigit4g1<hrest>=>の最大12月の価値への"0x"<hrest>と等しいです。[<hrest>]
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
ラインフィード炭<cr>=<lf>=復帰炭の<eoln>は<cr><lf>と等しいです。| <lf>。
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<sp>が等しい、「「<タブ>=」「<sp>| <タブ>| <eoln<wspace>=>」[<wspace>]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
<ストリング>が等しい、「「「[<の最もstrestな>]、「「「<の最もstrestな>は等し(<手紙>| <ケタ>| <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>...
-- 1プロトコルIdentifier(PI)を入れてあるファイル--定義<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> "}"
-- 「PI定義<piDefinition>=<protoName>「プロトコル識別子」、[「異形、-、」 <protoName>] 「「「[<attrList>]」」という」 「「[<parmList>]」」「属性」「記述」というパラメタは[「子供」ストリング]を結[「アドレス形式」ストリング][「解読」ストリング][「参照」ストリング]」:、:=「「「<encapList>」」」
-- a protocol name
<protoName> = pname
-- プロトコル名前<protoName>はpnameと等しいです。
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- パラメタ<parmList>のリストが<parm>と等しい、[「」、<parm>] …
Bierman, et al. Standards Track [Page 14] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[14ページ]。
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- パラメタ<parm>はlcname[<wspace>]と等しいです「(「[<wspace>]<nonNegNum>[<wspace>]」)」という。[<wspace>]
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- 」 「属性<attrList>のリストは<attr>[<wspace>]と等しい」[<wspace>] <attr>]…
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- 属性<attr>はlcname[<wspace>]と等しいです「(「[<wspace>]<nonNegNum>[<wspace>]」)」という。
-- a non-negative number
<nonNegNum> = number | hstr
-- 非負数<nonNegNum>は数と等しいです。| hstr
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- 」 「カプセル化のリストは<encapValue<encapList>=>[<wspace>]を評価する」[<wspace>] <encapValue>]…
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- カプセル化値の<encapValue>は<baseEncapValue>と等しいです。| <normalEncapValue>。
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- ベースカプセル化価値の<baseEncapValue>は<nonNegNum>と等しいです。
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- 正常なカプセル化価値の<normalEncapValue>は<protoName><wspace><nonNegNum>と等しいです。
-- comment
<two dashes> <text> <end-of-line>
-- コメント<twoは><テキスト><行末>を投げつけます。
3.2.4. Mapping of the Protocol Name
3.2.4. プロトコル名に関するマッピング
The "protoName" value, called the "protocol name" shall be an ASCII string consisting of one up to 64 characters from the following:
"protoName"値、「プロトコル名」と呼ばれているのが以下からの1つ最大64のキャラクタから成るASCIIストリングになるでしょう:
"A" through "Z"
"a" through "z"
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
plus(+)
「z」を通した「Z」“a"を通した「A」、「「9インチはそのうえ、(-) underbar(_)アスタリスク(*)を投げつけること」を通した0インチ(+)
The first character of the protocol name is limited to one of the following:
プロトコル名の最初のキャラクタは以下の1つに制限されます:
"A" through "Z"
"a" through "z"
「z」を通した「Z」“a"を通した「A」
Bierman, et al. Standards Track [Page 15] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[15ページ]。
"0" through "9"
「「9インチ」を通した0インチ
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:
これは名前か頭文字語特定がプロトコルであったならSHOULDを評価します。 ケースが重要であることに注意してください。 値はマッチというプロトコル名のSHOULDのために示されたプロトコルのための「最もよく知られている」名前か頭文字語を選択しました。 例えば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 SHOULDでは、この信頼すべき文書で見つけられるプロトコル名と一致した名になってください。 同様に子供、以下のUDPとTCP SHOULDでは、課題という見つけられるポートナンバー名と一致した名になってください。
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」でプロトコル名をprependedします、したがって、前の最初の手紙はダッシュに変わるかもしれません。
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
ftp、ftp-データ、whois++、sql*ネット、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.
同じプロトコル名が同じプロトコルの異なったカプセル化(protocolDirTableに異なったエントリーで表される)に割り当てられるのが、実際の実現で可能であることに注意してください。 protocolDirID INDEX値はストリングというプロトコル名ではなく、特定のプロトコルを定義します。
3.2.5. Mapping of the VARIANT-OF Clause
3.2.5. マッピング、異形、-、節
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.
参照プロトコル識別子マクロSHOULD NOTのどんな節(例えば、CHILDREN、ADDRESS-FORMAT)もプロトコル異形識別子マクロでコピーされて、与えられた節に、プロトコルの意味論は'異形'であるなら同じです。
Bierman, et al. Standards Track [Page 16] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[16ページ]。
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.
PARAMETERSとATTRIBUTES節が以来にプロトコル識別子に存在していて空の'ParamList'と'AttrList'であるに違いない、(すなわち、「パラメタ」{}「)、''代わりに調べられた参照プロトコル識別子マクロでは見つけられた」プロトコル異形識別子マクロにおけるプレゼント、'ParamList'、およびAttrListはそうであるに違いありません。
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.
'ianaAssigned'プロトコルが定義されるならそれがいかなる他の記録されたプロトコルの異形、次に、プロトコル識別子マクロSHOULDでないことにも注意してください。マクロの異形識別子について議定書の中で述べているバージョンの代わりに、使用されてください。
3.2.6. Mapping of the PARAMETERS Clause
3.2.6. パラメタ節に関するマッピング
The protocolDirParameters object provides an NMS the ability to turn on and off expensive probe resources. An agent may support a given parameter all the time, not at all, or subject to current resource load.
protocolDirParameters物は断続的に高価な徹底的調査リソースをターンする能力をNMSに供給します。 エージェントは絶えず、全く、または現在のリソース負荷を条件として与えられたパラメタを支持するかもしれません。
The PARAMETERS clause is a list of bit definitions which can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions may be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conforming agent may choose to implement a subset of zero or more of these PARAMETERS.
PARAMETERS節は直接ネットワークバイトオーダーにおける関連ProtocolDirParameters八重奏にコード化できる噛み付いている定義のリストです。 ゼロかさらに噛み付いている定義が存在しているかもしれません。 ビット0-7だけが、値をコード化しながら、有効です。 この節は与えられたプロトコルのために許容された全体のBITセットを定義します。 従っているエージェントは、ゼロの部分集合かこれらのPARAMETERSの以上を実行するのを選ぶかもしれません。
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
------------------------------------
テーブル3.1はパラメタビットを予約しました。------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
噛み付いている名前記述--------------------------------------------------------------------- 0 このプロトコルが上側の層を複数のパケットに断片化しても、このプロトコルの中で要約されたcountsFragments上位層プロトコルは正しく数えられるでしょう。 1 tracksSessionsは正しくよく知られているポートかソケットにセッションを始めて、次にその後ダイナミックに割り当てられたポートかソケットにそれらを移すプロトコル(例えば、TFTP)のすべてのパケットを結果と考えます。
Bierman, et al. Standards Track [Page 17] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[17ページ]。
The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but may be equal to zero (empty).
PARAMETERS節は、すべてのプロトコル識別子マクロ宣言で存在していなければなりませんが、ゼロに合わせるために等しいかもしれません(空の)。
3.2.6.1. Mapping of the 'countsFragments(0)' BIT
3.2.6.1. 'countsFragments(0)'ビットのマッピング
This bit indicates whether the probe is correctly attributing all fragmented packets of the specified protocol, even if individual frames carrying this protocol cannot be identified as such. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS.
このビットは、徹底的調査が正しくすべてを結果と考えているかどうかが指定されたプロトコルのパケットを断片化したのを示します、そういうものとしてこのプロトコルを運ぶ個々のフレームを特定できないでも。 徹底的調査は実際に、どんな組み立て直されたデータグラム(アドレス分析、フィルタリング、またはいかなる他の目的のためのも)もNMSに贈るのに必要でないことに注意してください。
This bit 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.
このビットは、断片化を支持するプロトコルに対応するprotocolDirParameters八重奏で設定されるだけであり、何らかのフォームで再アセンブリされなければなりません。 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.
このビットはprotocolDirTable INDEXの中の1つ以上のprotocolDirParameters八重奏で設定されるかもしれなくて、出来事では、エージェントは1個以上のプロトコル層で断片を数えることができます。
3.2.6.2. Mapping of the 'tracksSessions(1)' BIT
3.2.6.2. 'tracksSessions(1)'ビットのマッピング
The 'tracksSessions(1)' bit indicates whether frames which are part of remapped sessions (e.g. TFTP download sessions) are correctly counted by the probe. For such a protocol, the probe must usually analyze all packets received on the indicated interface, and maintain some state information, (e.g. the remapped UDP port number for TFTP).
'tracksSessions(1)'ビットは、再写像しているセッション(例えば、TFTPダウンロードセッション)の一部であるフレームが徹底的調査で正しく数えられるかどうかを示します。 そのようなプロトコルのために、探測装置は、通常、示されたインタフェースに受け取られたすべてのパケットを分析して、何らかの州の情報(例えば、TFTPのためのremapped UDPポートナンバー)を保守しなければなりません。
The semantics of the 'tracksSessions' parameter are independent of the other protocolDirParameters definitions, so this parameter MAY be combined with any other legal parameter configurations.
'tracksSessions'パラメタの意味論が他のprotocolDirParameters定義から独立しているので、このパラメタはいかなる他の法的なパラメタ構成にも結合されるかもしれません。
3.2.7. Mapping of the ATTRIBUTES Clause
3.2.7. 属性節に関するマッピング
The protocolDirType object provides an NMS with an indication of a probe's capabilities for decoding a given protocol, or the general attributes of the particular protocol.
protocolDirType物は与えられたプロトコルを解読するための徹底的調査の能力のしるし、または特定のプロトコルの一般属性をNMSに提供します。
The ATTRIBUTES clause is a list of bit definitions which are encoded into the associated instance of ProtocolDirType. The BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object.
ATTRIBUTES節はProtocolDirTypeの関連例にコード化される噛み付いている定義のリストです。 BIT定義はprotocolDirType MIB物のSYNTAX節で指定されます。
Bierman, et al. Standards Track [Page 18] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[18ページ]。
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
テーブル3.2は属性ビットを予約しました。------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
噛み付いている名前記述--------------------------------------------------------------------- 0 hasChildrenは、protocolDirTable(エージェントかマネージャのどちらかによる)で定義されたこのプロトコルの子供がいるかもしれないのを示します。 1 addressRecognitionCapableは、ホストとマトリクステーブル項目を発生させるのにこのプロトコルを使用できるのを示します。
The ATTRIBUTES clause MUST be present in all protocol-identifier macro declarations, but MAY be empty.
ATTRIBUTES節は、すべてのプロトコル識別子マクロ宣言で存在していなければなりませんが、空であるかもしれません。
3.2.8. Mapping of the DESCRIPTION Clause
3.2.8. 記述節に関するマッピング
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.
記述節はこのマクロによって特定されたプロトコルの原文の記述を提供します。 それに注意してください、それ、SHOULD NOTはCHILDREN、ADDRESS-FORMAT、DECODING、およびREFERENCE節でカバーされた項目に関する詳細を含んでいます。
The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations.
記述節はすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
3.2.9. Mapping of the CHILDREN Clause
3.2.9. 子供節に関するマッピング
The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections:
CHILDREN節は子供プロトコルの記述をそれらを支持するプロトコルに提供します。 それには、3つの小区分があります:
- Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed
- 分野/値に関する詳細は以前はよく子供プロトコルと、その選択の過程がどう実行されるかを選択していました。
- Details on how the value(s) are encoded in the protocol identifier
octet string
- 値がプロトコル識別子八重奏ストリングでどうコード化されるかに関する詳細
- Details on how child protocols are named with respect to their
parent protocol label(s)
- 子供プロトコルがそれらの親プロトコルラベルに関してどう命名されるかに関する詳細(s)
The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause.
CHILDREN節は'hasChildren(0)'BITがATTRIBUTES節で用意ができているすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
Bierman, et al. Standards Track [Page 19] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[19ページ]。
3.2.10. Mapping of the ADDRESS-FORMAT Clause
3.2.10. アドレス形式節に関するマッピング
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses.
ADDRESS-FORMAT節はアドレスをコード化するとき使用されるOCTET-STRING形式の記述を提供します。
This clause MUST be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause.
この節は'addressRecognitionCapable(1)'BITがATTRIBUTES節で用意ができているすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
3.2.11. Mapping of the DECODING Clause
3.2.11. 解読節に関するマッピング
The DECODING clause provides a description of the decoding procedure for the specified protocol. It contains useful decoding hints for the implementor, but SHOULD NOT over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required.
DECODING節は解読手順の記述を指定されたプロトコルに提供します。 それは作成者にとって、役に立つ解読ヒントを含んでいますが、SHOULD NOTはREFERENCE節で引用されたドキュメントの情報を模写し過ぎます。 それは情報が必要とした解読の完全な記述を含むかもしれません。
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection
as well as information on determining the start of the child
protocol.
これが含む'広げることができる'プロトコル('hasChildren(0)'BITはセットした)のために、子供プロトコルの始まりを決定することの情報と同様に子供選択に使用される分野のための情報を相殺して、タイプしてください。
For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses.
これが含む'addressRecognitionCapable'プロトコルには、アドレスを作るのに使用される分野のための情報を相殺して、タイプしてください。
The DECODING clause is optional, and MAY be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol.
DECODING節は、任意であり、REFERENCE節が指定されたプロトコルのための情報を解読するのにポインタを含んでいるなら、省略されるかもしれません。
3.2.12. Mapping of the REFERENCE Clause
3.2.12. 参照節に関するマッピング
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.
公的に利用可能な参考書類がこれのために存在するならそれについて議定書の中で述べてください、SHOULD、ここに記載されてください。 できれば、これは通常、URLになるでしょう。 まして、そして、それは、制御ボディーの名前とアドレスになるでしょう。
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the amount of information which may currently be obtained from an authoritative document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document.
CHILDREN、ADDRESS-FORMAT、およびDECODING節SHOULDは現在信頼すべき文書から得られるかもしれない情報量を制限します、Assigned民数記ドキュメント[RFC1700]などのように。 情報のどんな複製か言い換えも、信頼すべき文書と簡潔であって、一致しているべきです。
The REFERENCE clause is optional, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols).
しかし、REFERENCE節が任意である、SHOULD、正式の参照がプロトコル(特に標準プロトコルのための)のために存在するなら、実行されてください。
Bierman, et al. Standards Track [Page 20] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[20ページ]。
3.3. Evaluating an Index of the ProtocolDirTable
3.3. ProtocolDirTableのインデックスを評価します。
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]で指定されたINDEX符号化規則によると、protocolDirTable INDEX値を2OCTET STRINGsに変換した後に以下の評価をします。
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で分割可能な状態でprotocolDirID(長さは均等にそうであるに違いない)から始まって、プロトコル識別子は左で右に評価されます。 protocolDirParametersの長さはまさにprotocolDirIDストリング長の四分の一であるに違いありません。
Protocol-identifier parsing starts with the base layer identifier, which MUST be present, and continues for one or more upper layer identifiers, until all OCTETs of the protocolDirID have been used. Layers MUST NOT be skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can not exist.
プロトコル識別子構文解析は、存在しなければならない基層識別子から始まって、1つ以上の上側の層の識別子のために続きます、protocolDirIDのすべてのOCTETsが使用されるまで。 層をスキップしてはいけないので、'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.
プロトコル識別子ストリング(protocolDirIDの値である)が分析された後に、プロトコルパラメタストリングの各八重奏は、対応するプロトコル層に評価されて、適用されます。
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]).
1つ以上の値へのプロトコル識別子ラベル5月の地図。 例えば、それぞれがカプセル化を支持したので、'ip'は異なった値、1を5に写像します。 (RMONプロトコルIdentifier Macrosドキュメント[RFC2896]の'L3プロトコルIdentifiers'の下の'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'の同様に各子供はプロトコル識別子(各カプセル化(例えば、ether2の上のip、LLCの上のipなど)あたり1つ)を少なくとも5に写像するでしょう。
Bierman, et al. Standards Track [Page 21] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[21ページ]。
4. Base Layer Protocol Identifier Macros
4. 基層プロトコル識別子マクロ
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings.
protocolDirIDとprotocolDirParametersストリングを構成するのに以下のPROTOCOL IDENTIFIERマクロを使用できます。
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol.
識別子は、1つの層識別子がその時それぞれの要約のプロトコルのために加えて、ベース識別子を構成することによって、コード化されます。
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プロトコルIdentifier Macrosドキュメント[RFC2896]を参照してください。 他のPIマクロドキュメントが存在するかもしれなくて、作成者がPI Macroドキュメント[RFC2896]の使用なしでprotocolDirTableに居住するのが、可能であるべきであることに注意してください。
4.1. Base Identifier Encoding
4.1. 基地の識別子コード化
The first layer encapsulation is called the base identifier and it contains optional protocol-function information and the base layer (e.g. MAC layer) enumeration value used in this protocol identifier.
初層カプセル化はベース識別子と呼ばれます、そして、それはこのプロトコル識別子で使用される任意のプロトコル機能情報と基層(例えば、MACは層にする)列挙価値を含んでいます。
The base identifier is encoded as four octets as shown in figure 2.
ベース識別子は示されるとしての4つの八重奏としてコード化されて、2が中で計算するということです。
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
図2 ベース識別子形式+---+---+---+---+ | | | | | | f|op1|op2| m| | | | | | +---+---+---+---+ 八重奏| 1 | 1 | 1 | 1 | カウント
The first octet ('f') is the special function code, found in table
4.1. The next two octets ('op1' and 'op2') are operands for the
indicated function. If not used, an operand must be set to zero. The
last octet, 'm', is the enumerated value for a particular base layer
encapsulation, found in table 4.2. All four octets are encoded in
network-byte-order.
最初の八重奏('f')はテーブル4.1で見つけられた特別な機能コードです。 次の2つの八重奏('op1'と'op2')が示された機能のためのオペランドです。 使用されないなら、ゼロにオペランドを設定しなければなりません。 '最後の八重奏、'列挙された値はテーブル4.2で見つけられた特定の基層カプセル化のためのものです。 すべての4つの八重奏がネットワークバイトオーダーでコード化されます。
4.1.1. Protocol Identifier Functions
4.1.1. プロトコル識別子機能
The base layer identifier contains information about any special functions to perform during collections of this protocol, as well as the base layer encapsulation identifier.
基層識別子はこのプロトコルの収集の間に実行するどんな特別な機能の情報も含んでいます、基層カプセル化識別子と同様に。
The first three octets of the identifier contain the function code and two optional operands. The fourth octet contains the particular base layer encapsulation used in this protocol (fig. 2).
識別子の最初の3つの八重奏が機能コードと2つの任意のオペランドを含んでいます。 4番目の八重奏はこのプロトコル(図2)に使用される特定の基層カプセル化を含んでいます。
Bierman, et al. Standards Track [Page 22] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[22ページ]。
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
プロトコル識別子機能が割り当てられたテーブル4.1-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
機能ID Param1 Param2---------------------------------------------------- (0) 使用されないで、中古の(0)ワイルドカード1ではなく、0の中古でない(0)が使用しなかったなし(0)
4.1.1.1. Function 0: None
4.1.1.1. 機�%%BODY%%: なし
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分野(最初の八重奏)がゼロに合わせるために等しいなら、'op1'と'op2'分野(2番目と3番目の八重奏)も、ゼロに合わせるために等しくなければなりません。 この特別な値は、機能が全く残っている八重奏でコード化されたプロトコル識別子に適用されないのを示します。 識別子は正常なプロトコルカプセル化を表します。
4.1.1.2. Function 1: Protocol Wildcard Function
4.1.1.2. 機能1: プロトコルワイルドカード機能
The wildcard function (function-ID = 1), is used to aggregate counters, by using a single protocol value to indicate potentially many base layer encapsulations of a particular network layer protocol. A protocolDirEntry of this type will match any base-layer encapsulation of the same network layer protocol.
ワイルドカード機能(機能ID=1)は特定のネットワーク層プロトコルの潜在的に多くの基層カプセル化を示すのにただ一つのプロトコル値を使用することによってカウンタに集めるのにおいて使用されています。 このタイプのprotocolDirEntryは同じネットワーク層プロトコルのどんな基層カプセル化にも合うでしょう。
The 'op1' field (2nd octet) is not used and MUST be set to zero.
'op1'分野(2番目の八重奏)を使用されていなくて、ゼロに設定しなければなりません。
The 'op2' field (3rd octet) is not used and MUST be set to zero.
'op2'分野(3番目の八重奏)を使用されていなくて、ゼロに設定しなければなりません。
Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. 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.
'ベースカプセル化'でそれぞれのワイルドカードプロトコル識別子を定義しなければなりません。 このSHOULDは'標準'としてそうです。相互運用性目的のために可能であるとして。 可能な限り低いベースは値のSHOULDを層にします。選ばれています。 そのように'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ではなく、装置だけがそうするトークンリング。 それにもかかわらず、それは、ワイルドカードIPカプセル化を定義するのにether2基層を使用するべきです。 また、エージェントは、同じプロトコルのために個々のカプセル化のいくつかかすべてを数えるのを支持するかもしれません、ワイルドカード勘定に加えて。 RMON-2 MIB[RFC2021]が、エージェントが同じプロトコルの複数のカプセル化のためにカウンタを維持するのを必要としないことに注意してください。 それはエージェントが、その時々でprotocolDirTableでどのプロトコル組み合わせを許すかをどう決心するかに関する実現特有の問題です。
Bierman, et al. Standards Track [Page 23] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[23ページ]。
4.2. Base Layer Protocol Identifiers
4.2. 基層プロトコル識別子
The base layer is mandatory, and defines the base encapsulation of the packet and any special functions for this identifier.
基層は、義務的であり、この識別子のためにパケットのベースカプセル化とどんな特別な機能も定義します。
There are no suggested protocolDirParameters bits for the base layer.
基層のためのprotocolDirParametersビットは示されません。
The suggested 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の分野という対応する「名前」は基層のためのProtocolDirDescr分野への提案された値を以下に与えます。 しかしながら、実現が、適切な整数識別子値を使用するのに必要であるだけです。
For most base layer protocols, the protocolDirType field should contain bits set for the 'hasChildren(0)' and ' addressRecognitionCapable(1)' attributes. However, the special 'ianaAssigned' base layer should have no parameter or attribute bits set.
ほとんどの基層プロトコルのために、protocolDirType分野は'hasChildren(0)'と'addressRecognitionCapable(1)'属性に設定されたビットを含むべきです。 しかしながら、特別な'ianaAssigned'基層で、どんなパラメタも属性ビットも設定するはずがありません。
By design, only 255 different base layer encapsulations are supported. There are five base encapsulation values defined at this time. 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
--------------------------------------
テーブル4.2 値をコード化する基層--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
名前ID------------------ ether2 1 llc2は3vsnap4ianaAssigned5を折ります。
-- 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.
ether2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「また、イーサネットIIと呼ばれるDIXイーサネット。」 CHILDREN「タイプ分野が使用されているイーサネットIIの選んだ子供プロトコル。」 これは16ビットの分野です。 子供プロトコルがこのタイプ分野の後の最初の八重奏のときに出発すると考えられます。
Bierman, et al. Standards Track [Page 24] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[24ページ]。
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] 'ether2'のためのプロトコル識別子は'a'と'b'がイーサネットIIタイプ価値の高位バイトと下位バイトのネットワークバイトオーダーencodingsである[0.0.a.b]で従いました。
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.8.0、ether2で要約されたIPを定義します。
Children of 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'が16進のタイプ分野価値で続いたので、ether2の子供は命名されます。 上記の例は以下として宣言されるでしょう。 「ether2 0x0800」ADDRESS-FORMAT、「イーサネット・アドレスはネットワークオーダーで6つの八重奏です」。 DECODINGは「1500小数がイーサネットIIフレームを示すより大きい値をタイプするだけです」。 「下側の値は802.3に、カプセル化(以下を見る)を示します。」 REFERENCE、「Ether Type値の正式のリストはURLによって特定されます」。
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
" ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers ":、:= { 1 }
-- 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).
llcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、「Logical Link Control(LLC)802.2は議定書の中で述べる」記述。 CHILDREN、「LLC Source Service Access Point(SSAP)とDestination Service Access Point(DSAP)は子供プロトコルを選択するのに使用されます」。 長い間、それぞれのこれらは1つの八重奏です、最下位ビットが、コントロールビットであり、ほとんどの状況で覆い隠されるべきですが。 与えられたプロトコルに、SSAPとDSAP(かつての仮面の)は通常、同じです--各端は、それがクライアント/サーバプロトコルでサーバかそれともクライアントであるかをそれとなく知っています。 しかしながら、これはコンベンションにすぎません、そして、それらが異なるのは、可能です。 SSAPは最初に、子供プロトコルに取り組まされます。 なにも見つけられないなら、DSAPは代わりに合わせられています。 LLCが分野を制御した後に子供プロトコルが最初の八重奏のときに出発すると考えられます。
Bierman, et al. Standards Track [Page 25] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[25ページ]。
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
'llc'の子供がコード化される、[0.0 .0 .2] LLCのためのプロトコル識別子コンポーネントは[0.0.0.a]で'a'が子供への地図が議定書の中で述べるSAP値であるところに続きました。 例えば、以下のprotocolDirID-断片値 0.0.0.2.0.0.0.240
defines NetBios over LLC.
LLCの上でNetBiosを定義します。
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
'llc'が16進のSAP値で続いたので、子供は命名されます。 それで、上記の例は命名されたでしょう: llc 0xf0" ADDRESS-FORMAT、「アドレスはネットワークオーダーにおける、MACアドレスの6つの八重奏から成ります」。 「存在しているなら、アドレスからソースルーティングビットを剥取るべきです。」 DECODINGは「LLCには可変長プロトコルヘッダーがあるのに気付きます」。 3つの八重奏がいつもあります(DSAP(SSAP)は制御します)。 そこでDSAP、SSAP、および制御フィールドのコントロールビットの価値に依存するのは、制御情報の追加八重奏であるかもしれません。
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw 802.3
encapsulations). For 802.5 there is no other link layer
protocol.
LLCはいくつかの異なったメディアに存在している場合があります。 802.3と802.5において、存在は強制されます(ether2と生の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 }
「また、また、raw802.3も存在しているならraw802.3リンクレイヤプロトコルがすべてのLSAP値を利用するのが可能でないようにこれの上でプロトコルの特定の方法で優先するかもしれないのに注意してください。」 REFERENCE、「LLC LSAP値の正式のリストはIEEE Registration Authorityによって制御されます」。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000) -- Encapsulation
-- LLC(組織的でユニークな識別子、OUI=000)の上のスナップ--カプセル化
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
プロトコル-IDENTIFIER PARAMETERSを折ってください、ATTRIBUTES
Bierman, et al. Standards Track [Page 26] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[26ページ]。
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)、addressRecognitionCapable(1) 「LLCに制限されたメディアの上を走って、Sub-ネットワークAccessプロトコル(SNAP)はイーサネットIIプロトコルを許容するLLCプロトコルの上で層にされる」記述。 CHILDREN、「'スナップ'の子供はイーサネットIIタイプ値によって特定されます」。 SNAPプロトコルIdentifier分野(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.
'スナップ'の子供がコード化される、[0.0 .0 .3('スナップ'のためのプロトコル識別子)は]'a'と'b'がイーサネットIIタイプ価値の高位バイトと下位バイトである[0.0.a.b]で続きました。
For example, a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
例えば、以下のprotocolDirID-断片値 0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
IP/SNAPプロトコルを定義します。
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
このプロトコルの子供は16進のイーサネットIIタイプ価値があとに続いた'スナップ'と命名されます。 上記の例は命名されるでしょう:
snap 0x0800"
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 }
0×0800インチADDRESS-FORMAT「SNAPのためのアドレス形式はLLCのためのそれと同じであり」DECODINGを折ってください。「「SNAPはLLCの上に存在しているだけです」。 SSAPとDSAPの両方が0xAAになるでしょう、そして、単一管理八重奏は存在するでしょう。 その時、Organizationally Unique Identifier(OUI)の3つの八重奏とPIDの2つの八重奏があります。 「このカプセル化のために、OUIは0×000000でなければなりません(非ゼロOUIsに関して以下の'vsnap'を見てください)。」 REFERENCEは「IEEE Standardsオフィスによって割り当てSNAP Identifierが評価するされます」。 アドレスは以下の通りです。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 3 }
Bierman, et al. Standards Track [Page 27] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[27ページ]。
-- 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.
vsnapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「この疑似プロトコルはOUIを全く持っていないすべてのSNAPパケットを扱います」。 「OUIが評価するゼロを持っているものの詳細において、'スナップ'が上であることを見てください。」 CHILDREN、「'vsnap'の子供は3八重奏OUIによって選ばれます」。 PIDは分析されません。 子供プロトコルは、まず第一にSNAP PID分野の最初の八重奏であると考えられて、パケットの端まで続きます。 'vsnap'の子供がコード化される、[0.0 .0 .4('vsnap'のためのプロトコル識別子)は][0.a.b.c]で'a'、'b'、および'c'がネットワークバイトオーダーで、OUI分野の3つの八重奏であるところに続きました。
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
over vsnap.
例えば、以下のprotocolDirID-断片値 0.0.0.4.0.8.0.7、vsnapの上でアップル特有のセットのプロトコルを定義します。
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 }
それで、上記の例は命名されるでしょう: 「'vsnap0×080007'」 ADDRESS-FORMAT「アドレス形式が引き継がれるLLC'vsnap'。」 「その他の詳細のための'llc'プロトコル識別子を見てください。」 「'OUIが'スナップのための、非ゼロであり、SNAPプロトコルIdentifierが分析されないのと同じ」DECODING。 REFERENCEは「IEEE Standardsオフィスによって割り当てSNAP Identifierが評価するされます」。 アドレスは以下の通りです。 IEEE登録局気付虹彩Ringel IEEE規格部445Hoesレイン、私書箱1331ピスキャタウェイ(ニュージャージー)08855-1331電話+1 908 562 3813Fax: +1 908 562 1571" ::= { 4 }
Bierman, et al. Standards Track [Page 28] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[28ページ]。
-- 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).
プロトコル-IDENTIFIER PARAMETERSをianaAssignedした、ATTRIBUTES、記述、「このブランチは容易に他のリンクレイヤブランチで利用された階層的な形式に従わないプロトコルを含んでいます」。 通常、そのようなプロトコルが特定の'周知'の識別子形式に'ほとんど'従いますが、追加評価基準が使用されている、(例えば、構成ベース、)、適切なネットワークトラフィックの試験でプロトコル識別を難しいか不可能にする、(防止、使用されるのからのどんな'周知'のプロトコル識別子マクロも)
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)によって単に異なったポートナンバーに再写像されます。 これらのプロトコルは、protocolDirTableの'限られた伸展性'の特徴と同一視されていて、特別な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を見てください。) 新しいリンクレイヤのサポートは明らかに言い足されるでしょう、そして、より良い方法で表すことができないプロトコルだけが'ianaAssigned'プロトコルであるとみなされるでしょう。
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、「このプロトコルの子供はそれぞれの列挙されたプロトコルのためにプロトコル異形識別子マクロの中で'DECODING'節で説明された(できるだけ最も良い)実現の特定の手段で特定されます」。
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('ianaAssigned'のためのプロトコル識別子)は][0.0.a.b]で'a'、'b'が高位バイトのネットワークバイトオーダーencodingsであるところに続いて、特定のIANAのための列挙価値の下位バイトはプロトコルを割り当てました。
Bierman, et al. Standards Track [Page 29] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[29ページ]。
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
例えば、以下のprotocolDirID-断片値 0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
直接802.3で要約されたIPXプロトコルを定義します。
Children are named 'ianaAssigned' followed by the numeric value
of the particular IANA assigned protocol. The above example
would be named:
子供は特定のプロトコルが割り当てられたIANAの数値があとに続いた'ianaAssigned'と命名されます。 上記の例は命名されるでしょう:
'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 }
'ianaAssignedされました。1 '「DECODING「'ianaAssigned'基層は、疑似プロトコルであり、解読」にされません」。 REFERENCEは「プロトコルが割り当てられたIANAのそれぞれの子供の情報について個々のプロトコル-IDENTIFIERマクロについて言及します」。 ::= { 5 }
-- The following protocol-variant-identifier macro declarations are -- used to identify the RMONMIB IANA assigned protocols in a -- proprietary way, by simple enumeration.
-- プロトコルがaで割り当てられたRMONMIB IANAを特定するのに使用されて、以下のプロトコル異形識別子マクロ宣言はずっと単純枚挙法で独占です。
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
ipxOverRaw8023プロトコル-IDENTIFIER VARIANT-OF ipx PARAMETERS、ATTRIBUTES、記述、「この疑似プロトコルはIPXより多くの802.3のカプセル化について説明します、タイプ分野なしで」。
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
「このプロトコルに関する追加情報のためにIPXについてマクロを参照してください。」 DECODING、「802.3ヘッダーがLLCを示すときはいつも、プロトコル特有のセットはこれが'raw8023'パケットかそれとも本当の802.2パケットであるかを決定するために適用されるべき必要性をテストします」。 「これらのテストの本質は、'raw8023'のためにアクティブな子供プロトコルによって、このドキュメントの範囲を超えています。」 ::= ianaAssigned1--、[0.0 .0 .1] 802-1 Q0x05000001--、1Q_IANA、[5.0、.0、.1]
Bierman, et al. Standards Track [Page 30] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[30ページ]。
4.3. Encapsulation Layers
4.3. カプセル化層
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プロトコルディレクトリにおけるそのようなすべてのカプセル化を露出するかどうかが、実現特有の問題です。
4.3.1. IEEE 802.1Q
4.3.1. IEEE 802.1Q
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マクロ'802-1 Q'はVLANヘッダーのTCI部分でToken Ring Encapsulation(TR-encaps)ビットを露出しません。 RMON徹底的調査がLLC-象徴Ring(LLC-TR)を変換するかどうかがLLCネイティブの(LLC-N)形式にフレームをフォーマットしたのは、実現の特定の問題です、RMON収集の目的のために。
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との整列が基層アプローチ(すなわち、スナップとvsnapのサポート)を'潰れた'とまだ主張しているために、802dot1Qの子供は他の基層識別子の子供と異なって少しコード化されます。
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
802-1 Qプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「IEEE 802.1Q VLAN Encapsulationヘッダー。」
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マクロによって明らかに特定されないことに注意してください。 特定のRMON収集のためのデータ送信端末のifTypeはSNAPによってコード化されたTPIDに対してイーサネットでコード化された分野を特定できます、SNAPのコード化された形式が排他的にToken RingとFDDIメディアで使用されるので。 「また、TCI分野(TR- encapビットを含んでいる)に保持されなかった情報は全くprotocolDirIDストリングでこのPIマクロを利用することで特定されます。」
Bierman, et al. Standards Track [Page 31] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[31ページ]。
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'と'折れること'の基層はただ一つの識別子に結合されます、ゼロの値で。 他の基層はTable4.2から値を取っていてコード化されます。
802-1Q Base ID Values
---------------------
802-1 Q基地のID値---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
コード化をコード化する基地のテーブル4.2基地ID層------------------------------------- ether2 1 0 llc2 2は3 0vsnap4 4ianaAssigned5 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
802-1 Q子供層識別子形式+--------+--------+--------+--------+ | 基地| | | ID| ベース特有の形式| | | | +--------+--------+--------+--------+ | 1 | 3 | 八重奏カウント
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.
基地のID=0------------ イーサネットかVLANヘッダーについて来るLLC/SNAPヘッダーのどちらかと共にコード化されたペイロードのために、このプロトコルの子供は、ちょうど'ether2'のために説明されるように特定されるか、または基層を'折ります'。
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'のためのプロトコル識別子は'a'と'b'がイーサネットIIタイプ価値の高位バイトと下位バイトのネットワークバイトオーダーencodingsである[0.0.a.b]で従いました。
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.
例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.129.0.0.0.8.0、ether2でVLANによって要約されていた状態で、IPを定義します。
Bierman, et al. Standards Track [Page 32] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[32ページ]。
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-1 Q0x0800'。
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.
基地のID=2------------ (非SNAP)LLCヘッダーがVLANヘッダーについて来ていてコード化されたペイロードにおいて、このプロトコルの子供はちょうど'llc'基層のために説明されるように特定されます。
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値であるところに続きました。 例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.129.0.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
VLANによってLLCの上に要約されていた状態で、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-1 Q0x020000f0'
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.
基地のID=4------------ LLC/SNAP(非ゼロOUI)ヘッダーがVLANヘッダーについて来ていてコード化されたペイロードにおいて、このプロトコルの子供はちょうど'vsnap'基層のために説明されるように特定されます。
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'のためのプロトコル識別子)は][4.a.b.c]で'a'、'b'、および'c'がネットワークバイトオーダーで、OUI分野の3つの八重奏であるところに続きました。
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.
例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.129.0.4.8.0.7、VLANによってvsnapの上に要約されていた状態で、アップル特有のセットのプロトコルを定義します。
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'が16進法における3つの八重奏として表される<OUI>価値で続いたので、子供は命名されます、値4に設定された主な八重奏で。
So the above example would be named:
'802-1Q 0x04080007'.
それで、上記の例は命名されるでしょう: '802-1 Q0x04080007'。
Bierman, et al. Standards Track [Page 33] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[33ページ]。
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.
基地のID=5------------ 'ianaAssigned'プロトコルとして特定できるだけであるペイロードにおいて、このプロトコルの子供はちょうど'ianaAssigned'基層のために説明されるように特定されます。
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'のためのプロトコル識別子)は][5.0.a.b]で'a'と'b'が特定のプロトコルが割り当てられたIANAのための列挙価値の高位バイトと下位バイトのネットワークバイトオーダーencodingsであるところに続きました。
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.129.0.5.0.0.0.1
例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.129.0.5.0.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.
子供は特定のプロトコルが割り当てられたIANAの数値があとに続いた'802-1Q'と命名されます、5の値に設定された主な八重奏で。
Children are named '802-1Q' followed by the hexadecimal encoding
of the child identifier. The above example would be named:
子供は子供識別子の16進コード化があとに続いた'802-1Q'と命名されます。 上記の例は命名されるでしょう:
'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
}
'802-1 Q0x05000001'。 「"DECODING"VLANヘッダーとタグ付けをされた枠組構造は[IEEE802.1Q]で定義されます。」 REFERENCE、「802.1QプロトコルはVirtual Bridgedローカル・エリア・ネットワーク[IEEE802.1Q]のためにDraft Standardで定義されます」。 ::= ether2 0x8100(TPIDのイーサネットかSNAPコード化)はPDサイズと複雑さを減少させるために除かれた0×8100**を折ります。
5. Intellectual Property
5. 知的所有権
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
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証か、された試みの結果もコピーされます。
Bierman, et al. Standards Track [Page 34] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[34ページ]。
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事務局からこの仕様のユーザを得ることができます。」
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専務に情報を扱ってください。
6. Acknowledgements
6. 承認
This document was produced by the IETF RMONMIB Working Group.
このドキュメントはIETF RMONMIB作業部会によって製作されました。
The authors wish to thank the following people for their contributions to this document:
作者はこのドキュメントへの彼らの貢献について以下の人々に感謝したがっています:
Anil Singhal
Frontier Software Development, Inc.
コマツナギSinghal国境のソフトウェア開発Inc.
Jeanne Haney
Bay Networks
ジャンヌヘーニーベイネットワークス
Dan Hansen
Network General Corp.
ダンハンセンネットワーク一般社
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.
デヴィッドパーキンスDeskTalkシステムInc.
Skip Koppenhaver
Technically Elite, Inc.
Koppenhaverをスキップしてください、技術的にエリートのInc.
7. References
7. 参照
[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車線0021.000]LANエミュレーションサブワーキンググループ、B.エリントン、「バージョン1インチ、AF車線-0021.000、気圧フォーラム、IBM、1995年気圧でのLANエミュレーション--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ニューメキシコTEST-0080.000] ネットワークマネージメントサブワーキンググループ、サブワーキンググループのテストA.Bierman、「気圧ネットワークに、リモートなモニターしているMIB拡張子」、AFニューメキシコ-TEST-0080.000、気圧フォーラム、シスコシステムズ(1997年2月)。
Bierman, et al. Standards Track [Page 35] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[35ページ]。
[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.
IEEEコンピュータSocietyの[IEEE802.1D-1998]LAN MAN Standards Committee、「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(一般的な仕様)は3を分けます」。 「メディアアクセス制御(MAC)ブリッジ」(ISO/IECの最終的な不-15802-3(IEEE P802.1D/D17)米国電気電子技術者学会Inc.)は1998がそうするかもしれません。
[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.
IEEEコンピュータ社会の[IEEE802.1Q]LAN男性規格委員会、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「仮想のブリッジしているローカル・エリア・ネットワーク」は標準のP802.1Q/D11、米国電気電子技術者学会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.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J.
Davin, "Simple Network Management Protocol",
STD 15, RFC 1157, May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB
Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for
use with the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、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]ケースとJ.とMcCloghrieとK.とローズ、M.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」RFC1902(1996年1月)。
Bierman, et al. Standards Track [Page 36] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[36ページ]。
[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]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」、RFC1903、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]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための順応Statements」、RFC1904、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]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、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]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送する」」、RFC1906、1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB
(RMON-2)", RFC 2021, January 1997.
S.、「リモートネットワーク監視MIB(RMON-2)」、RFC2021 1997年1月の[RFC2021]Waldbusser。
[RFC2074] Bierman, A. and R. Iddon, "Remote Network
Monitoring MIB Protocol Identifiers", RFC 2074,
January 1997.
[RFC2074] BiermanとA.とR.Iddon、「リモートネットワーク監視MIBプロトコル識別子」、RFC2074、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2233] McCloghrie, K. and F. Kastenholz, "The
Interfaces Group MIB Using SMIv2", RFC 2233,
November 1997.
[RFC2233] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC 2271, January 1998.
[RFC2271] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2271、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] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2272、1998年1月。
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2273, January 1998.
[RFC2273] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2273、1998年1月。
Bierman, et al. Standards Track [Page 37] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[37ページ]。
[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]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2274、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、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2275、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]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC 2571, April 1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、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] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、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]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、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、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[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.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(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.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
Bierman, et al. Standards Track [Page 38] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[38ページ]。
[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.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote
Network Monitoring MIB Protocol Identifier
Macros", RFC 2896, August 2000.
[RFC2896] BiermanとA.とブッチとC.とR.Iddon、「リモートネットワーク監視MIBプロトコル識別子マクロ」、RFC2896、2000年8月。
8. IANA Considerations
8. IANA問題
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 protocolDirTableの特定のプロトコルをサポートするために任意のプロトコルIdentifier課題をしなければなりません。 そのようなプロトコルのためのプロトコルIdentifierマクロは'ianaAssigned'基層の下で定義されるでしょう(セクション3と4.2を見てください)。
At this time, only one protocol is defined under the ianaAssigned base layer, called 'ipxOverRaw8023' (see section 4.2).
'ipxOverRaw8023'は、このとき1つのプロトコルだけがianaAssigned基層の下で定義されると呼びました(セクション4.2を見てください)。
9. Security Considerations
9. セキュリティ問題
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.
このドキュメントはどんなネットワークの振舞いの定義ではなく、ネットワーク・プロトコルの原文の記述の構文と意味論についても議論します。 そういうものとして、セキュリティ問題は全くこのメモで提起されません。
Bierman, et al. Standards Track [Page 39] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[39ページ]。
10. Authors' Addresses
10. 作者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
カリフォルニア米国 アンディBiermanシスコシステムズInc.170の西タスマン・Driveサンノゼ、95134
Phone: +1 408-527-3711 EMail: abierman@cisco.com
以下に電話をしてください。 +1 408-527-3711 メールしてください: abierman@cisco.com
Chris Bucci Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
カリフォルニア米国 クリスブッチシスコシステムズInc.170の西タスマン・Driveサンノゼ、95134
Phone: +1 408-527-5337 EMail: cbucci@cisco.com
以下に電話をしてください。 +1 408-527-5337 メールしてください: cbucci@cisco.com
Robin Iddon c/o 3Com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh, EH1 1NE, UK
ロビンIddon気付3Com株式会社ブラックフライアーズ家40/50のBlackfrias通りエディンバラ、EH1 1NE、イギリス
Phone: +44 131.558.3888 EMail: None
以下に電話をしてください。 +44 131.558 .3888 メール: なし
Bierman, et al. Standards Track [Page 40] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[40ページ]。
Appendix A: Changes since RFC 2074
付録A: RFC2074以来の変化
The differences between RFC 2074 and this document are:
RFC2074とこのドキュメントの違いは以下の通りです。
- 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:
- RFC2074は標準化過程の上の参考書類(このドキュメント)と情報のドキュメント[RFC2896]に分割されました、標準化過程ドキュメントからほとんどのプロトコル識別子マクロを取り除くために。 - 管理アップデート。 作者(加えられた著作権)がSNMPフレームワークの決まり文句をアップデートしたと言い足します。 - 概要部をアップデートしました。 - セクション2.1はそうしなければなりません、とSHOULDテキストはテンプレート単位で言い足しました--いくつかの新学期の間に加えられたセクション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プロトコルIdentifier Macros Documentとの関係」(「気圧-RMON MIBとの関係」という加えられたセクション2.4)は意味変化が全くされなかったセクション3.2「プロトコル識別子マクロ形式」Butを書き直しました。 PIマクロ構文は、現在、BNF記法を使用することで詳細によりすばらしい指定されます。 - セクション3.2 .3 .1 「'countsFragments(0)'ビットのマッピング」--このセクションは、与えられたPIストリングにおける複数のprotocolDirParameters八重奏が'countsFragments'ビットを設定するのを許容するためにはっきりさせられました。 RFCバージョンは、ちょうど1つの八重奏がこのBITを設定できると言います。 それが複数の層で断片化を特定する役に立つ特徴であり、ほとんどのRMON-2エージェントが既にこれをしていたので、WGはこの明確化に同意しました。 - このドキュメントが基層カプセル化定義(RFC2074を通してセクション5.2)の後に終わるという「Encapsualtion層」という加えられたセクション4.3はIntellectual Property部を加えました--RFC2074部5.3を動かす、「L3:」 RFC2074の端、PI Reference[RFC2896]ドキュメントへの「基地のプロトコルIdentifiersの子供」(多くの新しいプロトコル識別子マクロがアプリケーション・プロトコルと非IPのために加えられた)はスタックについて議定書の中で述べます。 - 承認部をアップデートしました。
Bierman, et al. Standards Track [Page 41] RFC 2895 RMON PI Reference August 2000
Bierman、他 規格はRMONパイ参照2000年8月にRFC2895を追跡します[41ページ]。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Bierman, et al. Standards Track [Page 42]
Bierman、他 標準化過程[42ページ]
一覧
スポンサーリンク
