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
Network Working Group A. Bierman
Request for Comments: 2895 C. Bucci
Obsoletes: 2074 Cisco Systems, Inc.
Category: Standards Track R. Iddon
3Com, Inc.
August 2000
Remote Network Monitoring MIB Protocol Identifier Reference
远程网络监控MIB协议标识符参考
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring Management Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.
本备忘录定义了描述协议封装中协议层的符号，特别用于编码RMON-2 MIB（远程网络监控管理信息库）[RFC2021]中protocolDirTable的索引值。还包括标准协议目录基本层标识符的定义。
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON Protocol Identifier Macros document [RFC2896] now contains the non-normative portion of that specification.
RMON协议标识符文档[RFC2074]的第一个版本已分为标准跟踪参考部分（本文档）和信息文档。RMON协议标识符宏文档[RFC2896]现在包含该规范的非规范部分。
This document obsoletes RFC 2074.
本文件废除了RFC 2074。
Table of Contents
目录
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
The SNMP Management Framework presently consists of five major components:
SNMP管理框架目前由五个主要组件组成：
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC 2571[RFC2571]中描述的总体架构。
o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
o 为管理目的描述和命名对象和事件的机制。这种管理信息结构（SMI）的第一个版本称为SMIv1，并在STD 16、RFC 1155[RFC1155]、STD 16、RFC 1212[RFC1212]和RFC 1215[RFC1215]中进行了描述。第二个版本称为SMIv2，在STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]中进行了描述。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o 用于传输管理信息的消息协议。SNMP消息协议的第一个版本称为SNMPv1，在STD 15 RFC 1157[RFC1157]中进行了描述。SNMP消息协议的第二个版本不是Internet标准跟踪协议，称为SNMPv2c，在RFC 1901[RFC1901]和RFC 1906[RFC1906]中进行了描述。消息协议的第三个版本称为SNMPv3，在RFC 1906[RFC1906]、RFC 2572[RFC2572]和RFC 2574[RFC2574]中进行了描述。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905].
o 访问管理信息的协议操作。STD 15、RFC 1157[RFC1157]中描述了第一组协议操作和相关PDU格式。RFC 1905[RFC1905]中描述了第二组协议操作和相关PDU格式。
o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575].
o RFC 2573[RFC2573]中描述的一组基本应用程序和RFC 2575[RFC2575]中描述的基于视图的访问控制机制。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
有关当前SNMP管理框架的更详细介绍，请参见RFC 2570[RFC2570]。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB中的对象是使用SMI中定义的机制定义的。
This memo does not specify a MIB module.
此备忘录未指定MIB模块。
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
RMON-2 MIB[RFC2021]使用分层格式的八位字节字符串全局标识protocolDirTable中的各个协议封装。
This guide contains algorithms and the authoritative set of base layer protocol identifier macros, for use within INDEX values in the protocolDirTable.
本指南包含算法和基本层协议标识符宏的权威集，用于protocolDirTable中的索引值。
This is the second revision of this document, and is intended to replace the first half of the first RMON-2 Protocol Identifiers document. [RFC2074].
这是本文件的第二次修订，旨在取代第一份RMON-2协议标识符文件的前半部分。[RFC2074]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Several terms are used throughout this document, as well as in the RMON-2 MIB [RFC2021], that should be introduced:
本文件以及RMON-2 MIB[RFC2021]中使用了以下术语：
parent protocol: Also called 'parent'; The encapsulating protocol identifier for a specific protocol layer, e.g., IP is the parent protocol of UDP. Note that base layers cannot have parent protocols. This term may be used to refer to a specific encapsulating protocol, or it may be used generically to refer to any encapsulating protocol.
父协议：也称为“父协议”；特定协议层的封装协议标识符，例如IP是UDP的父协议。请注意，基本层不能有父协议。该术语可用于指代特定的封装协议，也可泛指任何封装协议。
child protocol: Also called 'child'; An encapsulated protocol identifier for a specific protocol layer. e.g., UDP is a child protocol of IP. This term may be used to refer to a specific encapsulated protocol, or it may be used generically to refer to any encapsulated protocol.
儿童协议：也称为“儿童”；特定协议层的封装协议标识符。e、 例如，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.)
层标识符：表示特定协议封装层或子层的八位字节字符串片段。一个片段正好由四个八位字节组成，按网络字节顺序编码。如果存在，协议的子层标识符之间必须具有唯一的值。（详见第3.3节。）
protocol: A particular protocol layer, as specified by encoding rules in this document. Usually refers to a single layer in a given encapsulation. Note that this term is sometimes used in the RMON-2 MIB [RFC2021] to name a fully-specified protocol-identifier string. In such a case, the protocol-identifier string is named for its upper-most layer. A named protocol may also refer to any encapsulation of that protocol.
协议：特定的协议层，由本文档中的编码规则指定。通常指给定封装中的单层。请注意，此术语有时在RMON-2 MIB[RFC2021]中用于命名完全指定的协议标识符字符串。在这种情况下，协议标识符字符串以其最上层命名。命名协议也可以引用该协议的任何封装。
protocol-identifier string: An octet string representing a particular protocol encapsulation, as specified by the encoding rules in this document. This string is identified in the RMON-2 MIB [RFC2021] as the protocolDirID object. A protocol-identifier string is composed of one or more layer-identifiers read from left to right. The left-most layer-identifier specifies a base layer encapsulation. Each layer-identifier to the right specifies a child layer protocol encapsulation.
协议标识符字符串：表示特定协议封装的八位字节字符串，由本文档中的编码规则指定。此字符串在RMON-2 MIB[RFC2021]中标识为protocolDirID对象。协议标识符字符串由从左到右读取的一个或多个层标识符组成。最左边的层标识符指定基本层封装。右侧的每个层标识符指定一个子层协议封装。
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协议标识符宏文档[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 variant宏和PI宏是用一组语法规则定义的（参见第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 variant宏标识的协议实际上是protocolDirTable中可能存在的已知封装的变体。这用于记录IANA分配的协议，需要这些协议来识别无法通过检查“适当的网络流量”（例如，携带协议的数据包）实际识别的协议。所有其他协议（可通过检查适当的
network traffic) SHOULD be documented using the protocol-identifier macro. (See section 3.2 for details.)
网络流量）应使用协议标识符宏进行记录。（详见第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.)
协议参数字符串：八位字节字符串，协议标识符中的每个层标识符包含一个协议参数。此字符串在RMON-2 MIB[RFC2021]中标识为protocolDirParameters对象。（详见第3.2.6节。）
protocolDirTable INDEX: A protocol-identifier and protocol-parameters octet string pair that have been converted to an INDEX value, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902].
protocolDirTable INDEX：根据RFC 1902[RFC1902]第7.7节中的编码规则，已转换为索引值的协议标识符和协议参数八位字符串对。
pseudo-protocol: A convention or algorithm used only within this document for the purpose of encoding protocol-identifier strings.
伪协议：仅在本文档中用于编码协议标识符字符串的约定或算法。
protocol encapsulation tree: Protocol encapsulations can be organized into an inverted tree. The nodes of the root are the base encapsulations. The children nodes, if any, of a node in the tree are the encapsulations of child protocols.
协议封装树：协议封装可以组织成一个倒树。根的节点是基本封装。树中节点的子节点（如果有）是子协议的封装。
This document is intended to identify the encoding rules for the OCTET STRING objects protocolDirID and protocolDirParameters. RMON-2 tables, such as those in the new Protocol Distribution, Host, and Matrix groups, use a local INTEGER INDEX (protocolDirLocalIndex) rather than complete protocolDirTable INDEX strings, to identify protocols for counting purposes. Only the protocolDirTable uses the protocolDirID and protocolDirParameters strings described in this document.
本文档旨在确定八位字符串对象protocolDirID和protocolDirParameters的编码规则。RMON-2表（如新协议分发、主机和矩阵组中的表）使用本地整数索引（protocolDirLocalIndex）而不是完整的protocolDirTable索引字符串来标识协议，以便进行计数。只有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.
本文档有意与RMON-2 MIB对象[RFC2021]分离，以允许在不重新发布MIB对象的情况下更新本文档。
This document does not discuss auto-discovery and auto-population of the protocolDirTable. This functionality is not explicitly defined by the RMON standard. An agent SHOULD populate the directory with the 'interesting' protocols on which the intended applications depend.
本文档不讨论protocolDirTable的自动发现和自动填充。RMON标准没有明确定义此功能。代理应使用预期应用程序所依赖的“有趣”协议填充目录。
The original RMON Protocol Identifiers document [RFC2074] contains the protocol directory reference material, as well as many examples of protocol identifier macros.
原始RMON协议标识符文档[RFC2074]包含协议目录参考资料，以及协议标识符宏的许多示例。
These macros have been moved to a separate document called the RMON Protocol Identifier Macros document [RFC2896]. This will allow the normative text (this document) to advance on the standards track with the RMON-2 MIB [RFC2021], while the collection of PI macros is maintained in an Informational RFC.
这些宏已移动到称为RMON协议标识符宏文档[RFC2896]的单独文档中。这将允许规范性文本（本文件）通过RMON-2 MIB[RFC2021]在标准轨道上前进，同时PI宏的集合将保存在信息RFC中。
The PI Macros document is intentionally separated from this document to allow updates to the list of published PI macros without any republication of MIB objects or encoding rules. Protocol Identifier macros submitted from the RMON working group and community at large (to the RMONMIB WG mailing list at 'rmonmib@ietf.org') will be collected, screened by the RMONMIB working group, and (if approved) added to a subsequent version of the PI Macros document.
PI宏文档有意与此文档分离，以允许在不重新发布MIB对象或编码规则的情况下更新已发布PI宏的列表。RMON工作组和整个社区提交的协议标识符宏（发送至RMONMIB WG邮件列表，地址为'rmonmib@ietf.org“）将由RMONMIB工作组收集、筛选，并（如果批准）添加到PI宏文件的后续版本中。
Macros submissions will be collected in the IANA's MIB files under the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the RMONMIB working group mailing list message archive file www.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.htm.
宏提交将收集在IANA的MIB文件中，目录为“ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/“在RMONMIB工作组邮件列表邮件存档文件www.ietf.org/mail-archive/working-groups/RMONMIB/current/maillist.htm中。
The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides RMON-like stats, host, matrix, and matrixTopN capability for NSAP address-based (ATM Adaption Layer 5, AAL-5) cell traffic.
ATM论坛已经标准化了“ATM网络远程监控MIB扩展”（ATM-RMON MIB）[AF-NM-TEST-0080.000]，它为基于NSAP地址（ATM适配层5，AAL-5）的信元流量提供了类似RMON的统计、主机、矩阵和矩阵TOPN功能。
It it possible to correlate ATM-RMON MIB data with packet-based RMON-2 [RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and 'portSelTable' are configured to provide the same level of port aggregation as used in the packet-based collection. This will require an ATM-RMON 'portSelectGroup' to contain a single port, in the case of traditional RMON dataSources.
可以将ATM-RMON MIB数据与基于数据包的RMON-2[RFC2021]集合相关联，但前提是ATM-RMON“portSelGrpTable”和“portSelTable”配置为提供与基于数据包的集合中使用的相同级别的端口聚合。对于传统的RMON数据源，这将要求ATM-RMON“portSelectGroup”包含一个端口。
The RMON PI document does not contain explicit PI macro support for "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, a probe must 'fit' the ATM encapsulation to one of the base layers defined in this document (i.e., llc, snap, or vsnap), regardless of how the raw data is obtained by the agent (e.g., VC-muxing vs. LLC-muxing, or routed vs. bridged formats). See section 3.2 for details on identifying and decoding a particular base layer.
RMON PI文档不包含对“ATM适配层5上的多协议封装”[RFC1483]或ATM论坛“ATM上的LAN仿真”（LANE）[AF-LANE-0021.000]的明确PI宏支持。相反，无论代理如何获取原始数据（例如，VC muxing vs.llc muxing，或routed vs.bridged Format），探测器必须将ATM封装“适合”到本文档中定义的一个基本层（即llc、snap或vsnap）。有关识别和解码特定基层的详细信息，请参见第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集合的数据源接口类型（ifType）来确定某些省略的封装细节：
RFC 1483 dataSource ifTypes: - aal5(49)
RFC 1483数据源ifTypes:-aal5（49）
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
These dataSources require implementation of the ifStackTable from the Interfaces MIB [RFC2233]. It is possible that some implementations will use dataSource values which indicate an ifType of 'atm(37)' (because the ifStackTable is not supported), however this is strongly discouraged by the RMONMIB WG.
这些数据源需要从接口MIB[RFC2233]实现ifStackTable。有些实现可能会使用指示ifType为“atm（37）”的数据源值（因为不支持ifStackTable），但是RMONMIB WG强烈反对这样做。
The RMON-2 Application Layer (AL) and Network Layer (NL) (host/matrix/topN) tables require that octet counters be incremented by the size of the particular frame, not by the size of the frame attributed to a given protocol.
RMON-2应用层（AL）和网络层（NL）（主机/矩阵/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').
探测实现必须使用AAL-5帧大小（而不是AAL-5有效负载大小或封装的MAC帧大小）作为“帧大小”，以增加RMON-2八位字节计数器（例如，“NLHOSTINOTETS”、“ALHOSTOUTCETS”）。
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的流量的数据包捕获相关的问题。因此，在RMON-1“captureBufferPacketData”MIB对象中是否表示填充八位字节（即RFC 1483 VC多路复用、桥接802.3或802.5通信量或车道通信量）是一个实现特定的问题。通常，捕获帧的第一个八位字节是目标MAC地址（DA）的第一个八位字节。
The RMON Protocol Identifiers Reference document is intended for use with the protocolDirTable within the RMON MIB. It is not relevant to any other MIB, or intended for use with any other MIB.
RMON协议标识符参考文档旨在与RMON MIB中的protocolDirTable一起使用。它与任何其他MIB无关，或与任何其他MIB一起使用。
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable-length string is converted to an OBJECT IDENTIFIER fragment, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index fragments are simply concatenated. (Refer to figures 1a - 1d below for more detail.)
protocolDirTable由两个八位字符串protocolDirID和protocolDirParameters索引。为了对表索引进行编码，根据RFC 1902[RFC1902]第7.7节中的编码规则，将每个可变长度字符串转换为对象标识符片段。然后将索引片段简单地连接起来。（有关更多详情，请参阅下面的图1a-1d。）
The first OCTET STRING (protocolDirID) is composed of one or more 4- octet "layer-identifiers". The entire string uniquely identifies a particular node in the protocol encapsulation tree. The second OCTET STRING, (protocolDirParameters) which contains a corresponding number of 1-octet protocol-specific parameters, one for each 4-octet layer-identifier in the first string.
第一个八位组字符串（protocolDirID）由一个或多个4-八位组“层标识符”组成。整个字符串唯一地标识协议封装树中的特定节点。第二个八位组字符串（protocolDirParameters），其中包含相应数量的1个八位组协议特定参数，第一个字符串中的每个4个八位组层标识符对应一个参数。
A protocol layer is normally identified by a single 32-bit value. Each layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of the 32-bit value in network byte order. If a particular protocol layer cannot be encoded into 32 bits, then it must be defined as an 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
协议层通常由单个32位值标识。每个层标识符在ProtocolDirID八位字节字符串索引中编码为四个子组件[a.b.c.d]，其中“a”-“d”以网络字节顺序表示32位值的每个字节。如果特定协议层无法编码为32位，则必须将其定义为“IANAASigned”协议（有关IANA分配协议的详细信息，请参阅下文）。
The following figures show the differences between the OBJECT IDENTIFIER and OCTET STRING encoding of the protocol identifier string.
下图显示了协议标识符字符串的对象标识符和八位字节字符串编码之间的差异。
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers required for the entire encapsulation of the named protocol. Note that the layer following the base layer usually identifies a network layer protocol, but this is not always the case, (most notably for children of the 'vsnap' base-layer).
N是命名协议的整个封装所需的协议层标识符的数量。请注意，基本层后面的层通常标识网络层协议，但情况并非总是如此（尤其是对于“vsnap”基本层的子层）。
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
When encoded in a protocolDirTable INDEX, each of the two strings must be preceded by a length sub-component. In this example, N equals '4', the first 'cnt' field would contain the value '16', and the second 'cnt' field would contain the value '4'.
在protocolDirTable索引中编码时，两个字符串的前面都必须有一个长度子组件。在本例中，N等于“4”，第一个“cnt”字段将包含值“16”，第二个“cnt”字段将包含值“4”。
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 3.5 of RFC 1902 [RFC1902].
尽管该示例表示四个封装协议，但在实践中，可能存在任何非零数量的层标识符，理论上仅受对象标识符长度限制，如RFC 1902[RFC1902]第3.5节所述。
The following PI identifier fragments are examples of some fully encoded protocolDirTable INDEX values for various encapsulations.
以下PI标识符片段是各种封装的一些完全编码的protocolDirTable索引值的示例。
-- HTTP; fragments counted from IP and above ether2.ip.tcp.www-http = 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
--HTTP；从IP和ether2.IP.tcp.www-http=16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.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
--SNMP over UDP/IP over SNAP SNAP.IP.UDP.SNMP=16.0.0.0.0.0.8.0.0.0.0.17.0.0.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
--SNMP over IPX over SNAP.IPX.SNMP=12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.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.ipxOverRaw8023.SNMP=12.0.0.0.0.0.1.0.0.144.15.3.0.0.0
-- IPX over LLC llc.ipx = 8.0.0.0.2.0.0.0.224.2.0.0
--IPX over LLC.IPX=8.0.0.0.2.0.0.0.0.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
--SNMP over UDP/IP over any link layer ether2.IP.UDP.SNMP 16.1.0.0.0.0.8.0.0.0.0.17.0.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；基本编码为IP over ether2 ether2.IP 8.1.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.atalk 8.0.0.0.0.128.155.2.0.0上应用第2阶段
-- AppleTalk Phase 2 over vsnap vsnap.apple-oui.atalk 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
--vsnap vsnap.apple-oui.atalk 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0上的AppleTalk第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”组件，则宏表示协议变量，而不是协议。本条款目前仅用于IANA分配的协议，在“IANAASigned”基本层下枚举。IANA分配的协议必须存在VariantOfPart组件。
The PI language defines the following keywords:
PI语言定义了以下关键字：
ADDRESS-FORMAT ATTRIBUTES CHILDREN DECODING DESCRIPTION PARAMETERS PROTOCOL-IDENTIFIER REFERENCE VARIANT-OF
地址格式属性子解码描述参数协议标识符参考变量
The PI language defines the following punctuation elements:
PI语言定义了以下标点符号元素：
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
An extended form of the BNF notation is used to specify the syntax of the PI language. The rules for this notation are shown below:
BNF符号的扩展形式用于指定PI语言的语法。此符号的规则如下所示：
* Literal values are specified in quotes, for example "REFERENCE"
* 文字值在引号中指定，例如“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>...
* 省略号用于表示前一项可能重复一次或多次，例如<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”
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"
<letter> = <lc> | <uc>
<digit> = "0" | "1" | ... | "9"
<hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
The following is the extended BNF notation for the grammar with starting symbol <piFile>:
以下是起始符号为<piFile>的语法的扩展BNF表示法：
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name <protoName> = pname
--协议名<protoName>=pname
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- a non-negative number <nonNegNum> = number | hstr
--非负数<nonNegNum>=number | hstr
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- comment
<two dashes> <text> <end-of-line>
-- comment
<two dashes> <text> <end-of-line>
The "protoName" value, called the "protocol name" shall be an ASCII string consisting of one up to 64 characters from the following:
称为“协议名称”的“protoName”值应为ASCII字符串，由以下一个最多64个字符组成：
"A" through "Z" "a" through "z" "0" through "9" dash (-) underbar (_) asterisk (*) plus(+)
“A”到“Z”A到“Z”0到“9”破折号（-）车底（）星号（*）加（+）
The first character of the protocol name is limited to one of the following:
协议名称的第一个字符仅限于以下字符之一：
"A" through "Z" "a" through "z"
“A”到“Z”或“A”到“Z”
"0" through "9"
“0”到“9”
This value SHOULD be the name or acronym identifying the protocol. Note that case is significant. The value selected for the protocol name SHOULD match the "most well-known" name or acronym for the indicated protocol. For example, the document indicated by the URL:
该值应为识别协议的名称或首字母缩略词。请注意，这种情况很重要。为协议名称选择的值应与指定协议的“最知名”名称或首字母缩略词匹配。例如，URL指示的文档：
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for children of IP SHOULD be given names consistent with the protocol names found in this authoritative document. Likewise, children of UDP and TCP SHOULD be given names consistent with the port number name assignments found in:
定义IP协议字段值，因此IP子级的协议标识符宏的名称应与此权威文档中的协议名称一致。同样，UDP和TCP的子级的名称应与以下文件中的端口号名称分配一致：
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
When the "well-known name" contains characters not allowed in protocol names, they MUST be changed to a dash character ("-") . In the event that the first character must be changed, the protocol name is prepended with the letter "p", so the former first letter may be changed to a dash.
当“已知名称”包含协议名称中不允许的字符时，必须将其更改为短划线字符（“-”）。在必须更改第一个字符的情况下，协议名称前面会加上字母“p”，因此前一个字母可能会更改为破折号。
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The following protocol names are legal:
例如，z39.50变为z39-50，914c/g变为914c-g。以下协议名称是合法的：
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
Note that it is possible in actual implementation that different encapsulations of the same protocol (which are represented by different entries in the protocolDirTable) will be assigned the same protocol name. The protocolDirID INDEX value defines a particular protocol, not the protocol name string.
注意，在实际实现中，相同协议的不同封装（由protocolDirTable中的不同条目表示）可能会被分配相同的协议名称。protocolDirID索引值定义特定协议，而不是协议名称字符串。
This clause is present for IANA assigned protocols only. It identifies the protocol-identifier macro that most closely represents this particular protocol, and is known as the "reference protocol". A protocol-identifier macro MUST exist for the reference protocol. When this clause is present in a protocol-identifier macro, the macro is called a 'protocol-variant-identifier'.
本条款仅适用于IANA分配的协议。它标识与此特定协议最接近的协议标识符宏，称为“参考协议”。引用协议必须存在协议标识符宏。当此子句出现在协议标识符宏中时，该宏称为“协议变量标识符”。
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-identifier macro SHOULD NOT be duplicated in the protocol-variant-identifier macro, if the 'variant' protocols' semantics are identical for a given clause.
如果给定子句的“变体”协议语义相同，则参考协议标识符宏中的任何子句（如子项、地址格式）不应在协议变体标识符宏中重复。
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e. "PARAMETERS {}") MUST be present in a protocol-variant-identifier macro, and the 'ParamList' and 'AttrList' found in the reference protocol-identifier macro examined instead.
由于PARAMETERS和ATTRIBUTES子句必须存在于协议标识符中，因此协议变量标识符宏中必须存在空的“ParamList”和“AttrList”（即“PARAMETERS{}”），而在参考协议标识符宏中必须找到“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.
请注意，如果定义的“IANAASigned”协议不是任何其他已记录协议的变体，则应使用协议标识符宏，而不是宏的协议变体标识符版本。
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是有效的编码值。此子句定义给定协议允许的整个位集。一致性代理可以选择实现零个或多个这些参数的子集。
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
------------------------------------
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but may be equal to zero (empty).
PARAMETERS子句必须出现在所有协议标识符宏声明中，但可以等于零（空）。
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索引中的多个protocolDirParameters八位组中设置该位。
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的重新映射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定义，因此此参数可以与任何其他合法参数配置组合。
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的关联实例中。位定义在protocolDirType MIB对象的语法子句中指定。
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
The ATTRIBUTES clause MUST be present in all protocol-identifier macro declarations, but MAY be empty.
ATTRIBUTES子句必须出现在所有协议标识符宏声明中，但可以为空。
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.
DESCRIPTION子句提供此宏标识的协议的文本描述。请注意，它不应包含有关子项、地址格式、解码和引用子句所涵盖的项目的详细信息。
The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations.
DESCRIPTION子句必须出现在所有协议标识符宏声明中。
The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections:
CHILDREN子句为支持它们的协议提供了子协议的描述。它有三个子部分：
- Details on the field(s)/value(s) used to select the child protocol, and how that selection process is performed
- 有关用于选择子协议的字段/值的详细信息，以及如何执行选择过程
- Details on how the value(s) are encoded in the protocol identifier octet string
- 有关如何在协议标识符八位字节字符串中对值进行编码的详细信息
- Details on how child protocols are named with respect to their parent protocol label(s)
- 有关如何根据其父协议标签命名子协议的详细信息
The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause.
在ATTRIBUTES子句中设置了“hasChildren（0）”位的所有协议标识符宏声明中都必须存在CHILDREN子句。
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses.
ADDRESS-FORMAT子句提供编码地址时使用的八位字节字符串格式的说明。
This clause MUST be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause.
此子句必须出现在所有协议标识符宏声明中，其中在ATTRIBUTES子句中设置了“addressRecognitionCapable（1）”位。
The DECODING clause provides a description of the decoding procedure for the specified protocol. It contains useful decoding hints for the implementor, but SHOULD NOT over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required.
解码条款提供指定协议的解码过程的描述。它包含对实现者有用的解码提示，但不应过度复制参考条款中引用的文档中的信息。它可能包含所需任何解码信息的完整描述。
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes offset and type information for the field(s) used for child selection as well as information on determining the start of the child protocol.
对于“可扩展”协议（“hasChildren（0）”位集），这包括用于子选择的字段的偏移量和类型信息，以及确定子协议开始的信息。
For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses.
对于“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子句包含指向指定协议的解码信息的指针，则可以省略DECODING子句。
If a publicly available reference document exists for this protocol it SHOULD be listed here. Typically this will be a URL if possible; if not then it will be the name and address of the controlling body.
如果存在本协议的公开参考文件，则应在此处列出。如果可能，这通常是一个URL；如果不是，则是控制机构的名称和地址。
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the amount of information which may currently be obtained from an authoritative document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document.
子项、地址格式和解码条款应限制当前可从权威文档（如分配号码文档[RFC1700]）获取的信息量。对信息的任何复制或解释应简短，并与权威文件保持一致。
The REFERENCE clause is optional, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols).
REFERENCE子句是可选的，但是如果协议（尤其是标准协议）存在权威引用，则应该实现REFERENCE子句。
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]中指定的索引编码规则，将protocolDirTable索引值转换为两个八位字节字符串后，将执行以下计算。
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.
协议标识符从左到右求值，从protocolDirID开始，其长度必须能被4整除。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.
协议标识符解析从必须存在的基本层标识符开始，然后继续解析一个或多个上层标识符，直到使用了protocolDirID的所有八位字节。不能跳过层，因此“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]).
协议标识符标签可以映射到多个值。例如，“ip”映射到5个不同的值，每个值对应一个受支持的封装。（请参阅RMON协议标识符宏文档[RFC2896]中“L3协议标识符”下的“IP”部分）。
It is important to note that these macros are conceptually expanded at implementation time, not at run time.
需要注意的是，这些宏是在实现时进行概念性扩展的，而不是在运行时。
If all the macros are expanded completely by substituting all possible values of each label for each child protocol, a list of all possible protocol-identifiers is produced. So 'ip' would result in 5 distinct protocol-identifiers. Likewise each child of 'ip' would map to at least 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, ip over LLC, etc.).
如果通过为每个子协议替换每个标签的所有可能值来完全扩展所有宏，则会生成所有可能协议标识符的列表。因此，“ip”将产生5个不同的协议标识符。同样，“ip”的每个子级将映射到至少5个协议标识符，每个封装一个（例如ether2上的ip、LLC上的ip等）。
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings.
以下协议标识符宏可用于构造protocolDirID和protocolDirParameters字符串。
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol.
通过构造基本标识符，然后为每个封装协议添加一个层标识符，对标识符进行编码。
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].
参考RMON协议标识符宏文档[RFC2896]，了解工作组发布的非基本层PI宏列表。注意，可能存在其他PI宏文档，实现者应该可以在不使用PI宏文档的情况下填充protocolDirTable[RFC2896]。
The first layer encapsulation is called the base identifier and it contains optional protocol-function information and the base layer (e.g. MAC layer) enumeration value used in this protocol identifier.
第一层封装称为基本标识符，它包含可选协议功能信息和该协议标识符中使用的基本层（例如MAC层）枚举值。
The base identifier is encoded as four octets as shown in figure 2.
基本标识符编码为四个八位字节，如图2所示。
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table 4.1. The next two octets ('op1' and 'op2') are operands for the indicated function. If not used, an operand must be set to zero. The last octet, 'm', is the enumerated value for a particular base layer encapsulation, found in table 4.2. All four octets are encoded in network-byte-order.
第一个八位组（“f”）是特殊功能代码，见表4.1。接下来的两个八位字节（“op1”和“op2”）是指定函数的操作数。如果未使用，则必须将操作数设置为零。最后一个八位字节“m”是特定基层封装的枚举值，见表4.2。所有四个八位字节均按网络字节顺序编码。
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).
标识符的前三个八位字节包含函数代码和两个可选操作数。第四个八位组包含本协议中使用的特定基本层封装（图2）。
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
If the function ID field (1st octet) is equal to zero, the 'op1' and 'op2' fields (2nd and 3rd octets) must also be equal to zero. This special value indicates that no functions are applied to the protocol identifier encoded in the remaining octets. The identifier represents a normal protocol encapsulation.
如果函数ID字段（第一个八位字节）等于零，“op1”和“op2”字段（第二个和第三个八位字节）也必须等于零。此特殊值表示未对编码在剩余八位字节中的协议标识符应用任何函数。标识符表示正常的协议封装。
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”字段（第二个八位字节）未使用，必须设置为零。
The 'op2' field (3rd octet) is not used and MUST be set to zero.
“op2”字段（第三个八位字节）未使用，必须设置为零。
Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. The lowest possible base layer value SHOULD be chosen. So, if an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation. If not then an encapsulation over LLC should be used, if permitted. And so on for each of the defined base layers.
必须根据“基本封装”定义每个通配符协议标识符。为了实现互操作性，这应尽可能成为“标准”。应选择可能的最低基层值。因此，如果允许在“ether2”上进行封装，则应将其用作基本封装。如果不允许，则应使用LLC封装。对于每个已定义的基础层，依此类推。
It should be noted that an agent does not have to support the non-wildcard protocol identifier over the same base layer. For instance a token ring only device would not normally support IP over the ether2 base layer. Nevertheless it should use the ether2 base layer for defining the wildcard IP encapsulation. The agent MAY also support counting some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RFC2021] does not require that agents maintain counters for multiple encapsulations of the same protocol. It is an implementation-specific matter as to how an agent determines which protocol combinations to allow in the protocolDirTable at any given time.
应该注意的是，代理不必在同一基础层上支持非通配符协议标识符。例如，令牌环专用设备通常不支持ether2基础层上的IP。然而，它应该使用ether2基本层来定义通配符IP封装。除了通配符计数外，代理还可以支持对相同协议的部分或全部单个封装进行计数。请注意，RMON-2 MIB[RFC2021]不要求代理为同一协议的多个封装维护计数器。代理如何确定在任何给定时间在protocolDirTable中允许哪些协议组合，这是一个实现特定的问题。
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）”属性设置的位。但是，特殊的“IANAASigned”基础层不应设置参数或属性位。
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种不同的基本层封装。此时定义了五个基本封装值。随着时间的推移，预计很少会添加新的基本封装（例如，对于新的媒体类型）。
Table 4.2 Base Layer Encoding Values
--------------------------------------
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2 Encapsulation
--乙醚2封装
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 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the protocol identifier for 'ether2' followed by [ 0.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the Ethernet-II type value.
此协议的子项编码为[0.0.0.1]，即“ether2”的协议标识符，后跟[0.0.a.b]，其中“a”和“b”是以太网II类型值的高阶字节和低阶字节的网络字节顺序编码。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
例如，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的子项命名为“ether2”，后跟十六进制的类型字段值。上述示例将被声明为：ether2 0x0800“地址格式”以太网地址是网络顺序中的6个八位字节。“解码”仅大于1500十进制的类型值表示以太网II帧；较低的值表示802.3封装（见下文）。“参考”乙醚类型值的权威列表由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 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Logical Link Control (LLC) 802.2 protocol."
CHILDREN
"The LLC Source Service Access Point (SSAP) and Destination
Service Access Point (DSAP) are used to select child protocols.
Each of these is one octet long, although the least significant
bit is a control bit and should be masked out in most situations.
Typically SSAP and DSAP (once masked) are the same for a given
protocol - each end implicitly knows whether it is the server or
client in a client/server protocol. This is only a convention,
however, and it is possible for them to be different. The SSAP
is matched against child protocols first. If none is found then
the DSAP is matched instead. The child protocol is deemed to
start at the first octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol identifier component for LLC followed by [ 0.0.0.a ] where 'a' is the SAP value which maps to the child protocol. For example, a protocolDirID-fragment value of: 0.0.0.2.0.0.0.240
“llc”的子项编码为[0.0.0.2]，llc的协议标识符组件后跟[0.0.0.a]，其中“a”是映射到子协议的SAP值。例如，protocolDirID片段值为：0.0.0.2.0.0.0.240
defines NetBios over LLC.
定义NetBios over LLC。
Children are named as 'llc' followed by the SAP value in hexadecimal. So the above example would have been named: llc 0xf0" ADDRESS-FORMAT "The address consists of 6 octets of MAC address in network order. Source routing bits should be stripped out of the address if present." DECODING "Notice that LLC has a variable length protocol header; there are always three octets (DSAP, SSAP, control). Depending on the value of the control bits in the DSAP, SSAP and control fields there may be an additional octet of control information.
子项命名为“llc”，后跟十六进制的SAP值。因此，上面的示例将被命名为：llc 0xf0“ADDRESS-FORMAT”。该地址由6个八位字节的MAC地址组成，按网络顺序排列。如果存在源路由位，则应将其从地址中剥离。“解码”注意LLC具有可变长度的协议头；始终有三个八位组（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 }
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
-- Encapsulation
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
-- Encapsulation
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP Protocol Identifier field (PID) is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
hasChildren(0),
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.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' are the high order byte and low order byte of the Ethernet-II type value.
“snap”的子项编码为[0.0.0.3]，即“snap”的协议标识符，后跟[0.0.a.b]，其中“a”和“b”是Ethernet II类型值的高阶字节和低阶字节。
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:
此协议的子协议名为“snap”，后跟十六进制的Ethernet 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 }
snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of Organizationally Unique Identifier (OUI) and two octets
of PID. For this encapsulation the OUI must be 0x000000 (see
'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation
--供应商SNAP over 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 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that have a
zero OUI value."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order.
For example, a protocolDirID-fragment value of: 0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols over vsnap.
例如，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>”字段以十六进制表示法表示为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 }
So the above example would be named:
'vsnap 0x080007'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
-- IANA Assigned Protocols
--IANA分配协议
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used).
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a different port number by one or more venders (e.g. SNMP). These protocols can be identified with the 'limited extensibility' feature of the protocolDirTable, and do not need special IANA assignments.
有时，一个或多个供应商（如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节。）将明确添加对新链路层的支持，并且只有无法以更好的方式表示的协议才会被视为“IANAASigned”协议。
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协议的整数值的四个八位组[0.0.a.b]。
Do not create children of this protocol unless you are sure that they cannot be handled by the more conventional link layers above." CHILDREN "Children of this protocol are identified by implementation-specific means, described (as best as possible) in the 'DECODING' clause within the protocol-variant-identifier macro for each enumerated protocol.
不要创建此协议的子级，除非您确定它们不能由上面更传统的链路层处理。此协议的“子级”子级通过特定于实现的方式进行标识，在每个枚举协议的协议变量标识符宏中的“解码”子句中描述（尽可能好）。
Children of this protocol are encoded as [ 0.0.0.5 ], the protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ] where 'a', 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
此协议的子协议编码为[0.0.0.5]，即“IANAASigned”的协议标识符，后跟[0.0.a.b]，其中“a”、“b”是特定IANA分配协议枚举值的高阶字节和低阶字节的网络字节顺序编码。
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:
子项命名为“IANAASigned”，后跟特定IANA分配协议的数值。上述示例将命名为：
'ianaAssigned 1' "
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
'ianaAssigned 1' "
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
-- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a
-- proprietary way, by simple enumeration.
-- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a
-- proprietary way, by simple enumeration.
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
Encapsulation layers are positioned between the base layer and the network layer. It is an implementation-specific matter whether a probe exposes all such encapsulations in its RMON-2 Protocol Directory.
封装层位于基础层和网络层之间。探测器是否在其RMON-2协议目录中公开所有此类封装是实现特有的问题。
RMON probes may encounter 'VLAN tagged' frames on monitored links. The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and [IEEE802.1D-1998], define an encapsulation layer inserted after the MAC layer and before the network layer. This section defines a PI macro which supports most (but not all) features of that encapsulation layer.
RMON探测器可能会在受监控链路上遇到“VLAN标记”帧。IEEE虚拟局域网（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-1Q”没有公开VLAN报头TCI部分中的令牌环封装（TR encaps）位。为了RMON收集的目的，RMON探测器是否将LLC令牌环（LLC-TR）格式的帧转换为LLC本机（LLC-N）格式是一个实现特定的问题。
In order to support the Ethernet and LLC-N formats in the most efficient manner, and still maintain alignment with the RMON-2 ' collapsed' base layer approach (i.e., support for snap and vsnap), the children of 802dot1Q are encoded a little differently than the children of other base layer identifiers.
为了以最有效的方式支持以太网和LLC-N格式，并且仍然保持与RMON-2“折叠”基本层方法的一致性（即，支持snap和vsnap），802dot1Q的子项编码与其他基本层标识符的子项略有不同。
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not explicitly identified by this PI macro. Ethernet-encoded vs. SNAP-encoded TPID fields can be identified by the ifType of the data source for a particular RMON collection, since the SNAP-encoded format is used exclusively on Token Ring and FDDI media. Also, no information held in the TCI field (including the TR-encap bit) is identified in protocolDirID strings utilizing this PI macro."
请注意，此PI宏未明确标识TPID字段的特定编码。以太网编码与SNAP编码的TPID字段可以通过特定RMON集合的数据源的ifType来识别，因为SNAP编码格式专门用于令牌环和FDDI介质。此外，在使用此PI宏的protocolDirID字符串中，没有识别TCI字段中保存的信息（包括TR encap位）。”
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头之后的特定基本编码。其余三个字节的使用与所示基本层编码的定义完全相同。
In order to simplify the child encoding for the most common cases, the 'ether2' and 'snap' base layers are combined into a single identifier, with a value of zero. The other base layers are encoded with values taken from Table 4.2.
为了简化最常见情况下的子编码，“ether2”和“snap”基本层组合成一个值为零的标识符。其他基层采用表4.2中的值进行编码。
802-1Q Base ID Values
---------------------
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
The generic child layer-identifier format is shown below:
通用子层标识符格式如下所示：
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the Ethernet-II type value.
子项编码为[0.0.129.0]，即“802-1Q”的协议标识符，后跟[0.0.a.b]，其中“a”和“b”是以太网II类型值的高阶字节和低阶字节的网络字节顺序编码。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.0.0.8.0 defines IP, VLAN-encapsulated in ether2.
例如，protocolDirID片段值：0.0.0.1.0.0.129.0.0.0.8.0定义了封装在ether2中的IP和VLAN。
Children of this format are named as '802-1Q' followed by the type field value in hexadecimal.
此格式的子项命名为“802-1Q”，后跟十六进制的类型字段值。
So the above example would be declared as: '802-1Q 0x0800'.
因此，上面的示例将被声明为：“802-1Q 0x0800”。
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the SAP value which maps to the child protocol. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.2.0.0.240
子项编码为[0.0.129.0]，802.1Q的协议标识符组件，后跟[2.0.0.a]，其中“a”是映射到子协议的SAP值。例如，protocolDirID片段值为：0.0.0.1.0.0.129.0.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
定义NetBios，通过LLC封装的VLAN。
Children are named as '802-1Q' followed by the SAP value in hexadecimal, with the leading octet set to the value 2.
子项命名为“802-1Q”，后跟十六进制的SAP值，前导八位字节设置为值2。
So the above example would have been named: '802-1Q 0x020000f0'
因此，上面的示例将被命名为：“802-1Q 0x0200000f0”
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.
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order.
子项编码为[0.0.129.0]，即“802-1Q”的协议标识符，后跟[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定义了苹果特定的协议集，即通过vsnap封装的VLAN。
Children are named as '802-1Q' followed by the <OUI> value, which is represented as 3 octets in hexadecimal notation, with a leading octet set to the value 4.
子项命名为“802-1Q”，后跟<OUI>值，以十六进制表示法表示为3个八位字节，前导八位字节设置为值4。
So the above example would be named: '802-1Q 0x04080007'.
因此，上面的示例将命名为：“802-1Q 0x04080007”。
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
子项编码为[0.0.129.0]，是“802-1Q”的协议标识符，后跟[5.0.a.b]，其中“a”和“b”是特定IANA分配协议枚举值的高阶字节和低阶字节的网络字节顺序编码。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.5.0.0.0.1
例如，protocolDirID片段值为：0.0.0.1.0.0.129.0.5.0.0.0.1
defines the IPX protocol, VLAN-encapsulated directly in 802.3
定义IPX协议，即直接封装在802.3中的VLAN
Children are named '802-1Q' followed by the numeric value of the particular IANA assigned protocol, with a leading octet set to the value of 5.
子项命名为“802-1Q”，后跟特定IANA分配协议的数值，前导八位组的值设置为5。
Children are named '802-1Q' followed by the hexadecimal encoding of the child identifier. The above example would be named:
子项命名为“802-1Q”，后跟子标识符的十六进制编码。上述示例将命名为：
'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-1Q 0x05000001'. "
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity
}
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可供发布的权利主张副本和任何许可证保证副本，或试图
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执行董事。
This document was produced by the IETF RMONMIB Working Group.
本文件由IETF RMONMIB工作组编制。
The authors wish to thank the following people for their contributions to this document:
作者希望感谢以下人士对本文件的贡献：
Anil Singhal Frontier Software Development, Inc.
Anil Singhal Frontier软件开发公司。
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.
David Perkins DeskTalk系统公司。
Skip Koppenhaver Technically Elite, Inc.
Skip Koppenhaver Technical Elite公司。
[AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995.
[AF-LANE-0021.000]LAN仿真子工作组，B.Ellington，“ATM上的LAN仿真-1.0版”，AF-LANE-0021.000，ATM论坛，IBM，1995年1月。
[AF-NM-TEST-0080.000] Network Management Sub-working Group, Test Sub-working Group, A. Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997.
[AF-NM-TEST-0080.000]网络管理子工作组，测试子工作组，A.Bierman，“ATM网络的远程监控MIB扩展”，AF-NM-TEST-0080.000，ATM论坛，思科系统，1997年2月。
[IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE Computer Society, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specification -- Part 3: Media Access Control (MAC) Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Electrical and Electronics Engineers, Inc., May 1998.
[IEEE802.1D-1998]IEEE计算机学会局域网城域网标准委员会，“信息技术——系统间的电信和信息交换——局域网和城域网——通用规范——第3部分：媒体访问控制（MAC）网桥”，ISO/IEC最终DIS 15802-3（IEEE P802.1D/D17）电气和电子工程师协会，1998年5月。
[IEEE802.1Q] LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D11, Institute of Electrical and Electronics Engineers, Inc., July 1998.
[IEEE802.1Q]IEEE计算机协会局域网标准委员会，“局域网和城域网的IEEE标准：虚拟桥接局域网”，标准草案P802.1Q/D11，电气和电子工程师协会，1998年7月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1155]Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议”，STD 15，RFC 1157，1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]Rose，M.和K.McCloghrie，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]Rose，M.，“定义用于SNMP的陷阱的约定”，RFC1215，1991年3月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483]Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[RFC1902]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的管理信息结构”，RFC 1902，1996年1月。
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的文本约定”，RFC 1903，1996年1月。
[RFC1904] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[RFC1904]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的一致性声明”，RFC 1904，1996年1月。
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)"", RFC 1906, January 1996.
[RFC1906]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
[RFC2021]Waldbusser，S.，“远程网络监控MIB（RMON-2）”，RFC 20211997年1月。
[RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997.
[RFC2074]Bierman，A.和R.Iddon，“远程网络监控MIB协议标识符”，RFC 2074，1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, November 1997.
[RFC2233]McCloghrie，K.和F.Kastenholz，“使用SMIv2的接口组MIB”，RFC 2233，1997年11月。
[RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
[RFC2271]Harrington，D.，Presohn，R.和B.Wijnen，“描述SNMP管理框架的体系结构”，RFC 22711998年1月。
[RFC2272] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998.
[RFC2272]Case，J.，Harrington D.，Presohn R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2272，1998年1月。
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998.
[RFC2273]Levi，D.，Meyer，P.和B.Stewart，“SNMPv3应用”，RFC 2273，1998年1月。
[RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
[RFC2274]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 2274，1998年1月。
[RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998.
[RFC2275]Wijnen，B.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，RFC 22751998年1月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[RFC2570]Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准网络管理框架第3版简介”，RFC 25701999年4月。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[RFC2571]Harrington，D.，Presohn，R.和B.Wijnen，“描述SNMP管理框架的体系结构”，RFC 2571，1999年4月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572]Case，J.，Harrington D.，Presohn R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[RFC2573]Levi，D.，Meyer，P.和B.Stewart，“SNMPv3应用”，RFC 2573，1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版基于用户的安全模型（USM）”，RFC 2574，1999年4月。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575]Wijnen，B.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，RFC 2575，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.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros", RFC 2896, August 2000.
[RFC2896]Bierman，A.，Bucci，C.和R.Iddon，“远程网络监控MIB协议标识符宏”，RFC 28962000年8月。
The protocols identified in this specification are almost entirely defined in external documents. In some rare cases, an arbitrary Protocol Identifier assignment must be made in order to support a particular protocol in the RMON-2 protocolDirTable. Protocol Identifier macros for such protocols will be defined under the ' ianaAssigned' base layer (see sections 3. and 4.2).
本规范中确定的协议几乎全部在外部文件中定义。在某些罕见的情况下，为了支持RMON-2协议目录中的特定协议，必须进行任意协议标识符分配。此类协议的协议标识符宏将在“IANAASigned”基本层下定义（见第3.2节和第4.2节）。
At this time, only one protocol is defined under the ianaAssigned base layer, called 'ipxOverRaw8023' (see section 4.2).
此时，IANAASigned基础层下仅定义了一个协议，称为“ipxOverRaw8023”（见第4.2节）。
This document discusses the syntax and semantics of textual descriptions of networking protocols, not the definition of any networking behavior. As such, no security considerations are raised by this memo.
本文档讨论网络协议文本描述的语法和语义，而不是任何网络行为的定义。因此，本备忘录未提出任何安全考虑。
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
安迪·比尔曼思科系统公司，美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Chris Bucci Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Robin Iddon c/o 3Com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh, EH1 1NE, UK
Robin Iddon c/o 3Com Inc.Blackfriars House 40/50 Blackfrias Street Edinburgh，EH1 1NE，英国
Phone: +44 131.558.3888 EMail: None
电话：+44131.558.3888电子邮件：无
Appendix A: Changes since RFC 2074
附录A：自RFC 2074以来的变化
The differences between RFC 2074 and this document are:
RFC 2074与本文件之间的差异如下：
- RFC 2074 has been split into a reference document (this document) on the standards track and an informational document [RFC2896], in order to remove most protocol identifier macros out of the standards track document. - Administrative updates; added an author, added copyrights, updated SNMP framework boilerplate; - Updated overview section. - Section 2.1 MUST, SHOULD text added per template - Section 2.1 added some new terms - parent protocol - child protocol - protocol encapsulation tree - Added section 2.3 about splitting into 2 documents:
- RFC 2074已分为标准轨道上的参考文件（本文件）和信息性文件[RFC2896]，以便从标准轨道文件中删除大多数协议标识符宏。-行政更新；添加作者，添加版权，更新SNMP框架样板文件；-更新概述部分第2.1节必须，如果按照模板添加文本-第2.1节添加了一些新术语-父协议-子协议-协议封装树-添加了第2.3节关于拆分为2个文档：
"Relationship to the RMON Protocol Identifier Macros Document" - Added section 2.4 "Relationship to the ATM-RMON MIB" - rewrote section 3.2 "Protocol Identifier Macro Format" But no semantic changes were made; The PI macro syntax is now specified in greater detail using BNF notation. - Section 3.2.3.1 "Mapping of the 'countsFragments(0)' BIT" - this section was clarified to allow multiple protocolDirParameters octets in a given PI string to set the 'countsFragments' bit. The RFC version says just one octet can set this BIT. It is a useful feature to identify fragmentation at multiple layers, and most RMON-2 agents were already doing this, so the WG agreed to this clarification. - Added section 4.3 "Encapsualtion Layers" - This document ends after the base layer encapsulation definitions (through RFC 2074, section 5.2) - Added Intellectual Property section - Moved RFC 2074 section 5.3 "L3: Children of Base Protocol Identifiers" through the end of RFC 2074, to the PI Reference [RFC2896] document, in which many new protocol identifier macros were added for application protocols and non-IP protocol stacks. - Acknowledgements section has been updated
“与RMON协议标识符宏文件的关系”-增加了第2.4节“与ATM-RMON MIB的关系”-重写了第3.2节“协议标识符宏格式”，但未进行语义更改；现在使用BNF符号更详细地指定PI宏语法。-第3.2.3.1节“countsFragments（0）”位的映射”-本节已澄清，以允许给定PI字符串中的多个protocolDirParameters八位字节设置“countsFragments”位。RFC版本说只有一个八位组可以设置这个位。识别多层碎片是一个有用的功能，大多数RMON-2代理已经在这样做，因此工作组同意这一澄清。-增加了第4.3节“封装层”-本文件在基本层封装定义之后结束（通过RFC 2074，第5.2节）-增加了知识产权部分-将RFC 2074第5.3节“L3：基本协议标识符的子项”通过RFC 2074的结尾移至PI参考[RFC2896]文件，其中为应用程序协议和非IP协议栈添加了许多新的协议标识符宏。-确认部分已更新
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。