draft-ietf-rmonmib-rmonprot-ref-00.txt   rfc2895.txt 
RMONMIB Working Group Andy Bierman Network Working Group A. Bierman
Internet Draft Cisco Systems, Inc. Request for Comments: 2895 C. Bucci
Chris Bucci Obsoletes: 2074 Cisco Systems, Inc.
Cisco Systems, Inc. Category: Standards Track R. Iddon
Robin Iddon 3Com, Inc.
3Com, Inc. August 2000
16 November 1998
Remote Network Monitoring MIB Protocol Identifier Reference Remote Network Monitoring MIB Protocol Identifier Reference
<draft-ietf-rmonmib-rmonprot-ref-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, and Internet community, and requests discussion and suggestions for
its working groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (2000). All Rights Reserved.
1id-abstracts.txt listing contained in the Internet- Drafts Shadow
Directories on ftp.ietf.org, nic.nordu.net, venera.isi.edu, or
munnari.oz.au.
Distribution of this document is unlimited. Please send comments to the Abstract
RMONMIB Working Group, <rmonmib@cisco.com>.
1. Copyright Notice 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.
Copyright (C) The Internet Society (1998). All Rights Reserved. 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.
2. Abstract This document obsoletes RFC 2074.
This memo defines a notation describing protocol layers in a protocol Table of Contents
encapsulation, specifically for use in encoding INDEX values for the
protocolDirTable, found in the RMON-2 MIB [RFC2021]. The definitions for
the standard protocol directory base layer identifiers are also
included.
The first version of the RMON Protocol Identifiers Document [RFC2074] 1 The SNMP Network Management Framework .......................... 3
has been split into a standards-track Reference portion (this document), 2 Overview ....................................................... 3
and an Informational document. The RMON Protocol Identifier Macros 2.1 Terms ........................................................ 4
document [RMONPROT_MAC] now contains the non-normative portion of that 2.2 Relationship to the Remote Network Monitoring MIB ............ 6
specification. 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
3. Table of Contents 1. The SNMP Network Management Framework
1 Copyright Notice ................................................ 1 The SNMP Management Framework presently consists of five major
2 Abstract ........................................................ 2 components:
3 Table of Contents ............................................... 3
4 The SNMP Network Management Framework ........................... 4
5 Overview ........................................................ 5
5.1 Terms ......................................................... 5
5.2 Relationship to the Remote Network Monitoring MIB ............. 8
5.3 Relationship to the RMON Protocol Identifier Macros Document
.............................................................. 8
5.4 Relationship to the ATM-RMON MIB .............................. 9
5.4.1 Port Aggregation ............................................ 9
5.4.2 Encapsulation Mappings ...................................... 9
5.4.3 Counting ATM Traffic in RMON-2 Collections .................. 10
5.5 Relationship to Other MIBs .................................... 10
6 Protocol Identifier Encoding .................................... 10
6.1 ProtocolDirTable INDEX Format Examples ........................ 13
6.2 Protocol Identifier Macro Format .............................. 14
6.2.1 Lexical Conventions ......................................... 14
6.2.2 Notation for Syntax Descriptions ............................ 14
6.2.3 Grammar for the PI Language ................................. 15
6.2.4 Mapping of the Protocol Name ................................ 17
6.2.5 Mapping of the VARIANT-OF Clause ............................ 18
6.2.6 Mapping of the PARAMETERS Clause ............................ 18
6.2.6.1 Mapping of the 'countsFragments(0)' BIT ................... 19
6.2.6.2 Mapping of the 'tracksSessions(1)' BIT .................... 20
6.2.7 Mapping of the ATTRIBUTES Clause ............................ 20
6.2.8 Mapping of the DESCRIPTION Clause ........................... 20
6.2.9 Mapping of the CHILDREN Clause .............................. 21
6.2.10 Mapping of the ADDRESS-FORMAT Clause ....................... 21
6.2.11 Mapping of the DECODING Clause ............................. 21
6.2.12 Mapping of the REFERENCE Clause ............................ 22
6.3 Evaluating an Index of the ProtocolDirectoryTable ............ 22
7 Base Layer Protocol Identifier Macros ........................... 23
7.1 Base Identifier Encoding ...................................... 23
7.1.1 Protocol Identifier Functions ............................... 24
7.1.1.1 Function 0: None .......................................... 24
7.1.1.2 Function 1: Protocol Wildcard Function .................... 25
7.2 Base Layer Protocol Identifiers ............................... 25
7.3 Encapsulation Layers .......................................... 33
7.3.1 IEEE 802.1Q ................................................. 33
8 Intellectual Property ........................................... 36
9 Acknowledgements ................................................ 37
10 References ..................................................... 38
11 Security Considerations ........................................ 41
12 Authors' Addresses ............................................. 41
13 Full Copyright Statement ....................................... 42
4. The SNMP Network Management Framework o An overall architecture, described in RFC 2571 [RFC2571].
The SNMP Management Framework presently consists of five major o Mechanisms for describing and naming objects and events for the
components: 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 An overall architecture, described in RFC 2271 [RFC2271]. 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 Mechanisms for describing and naming objects and events for the o Protocol operations for accessing management information. The
purpose of management. The first version of this Structure of first set of protocol operations and associated PDU formats is
Management Information (SMI) is called SMIv1 and described in RFC described in STD 15, RFC 1157 [RFC1157]. A second set of protocol
1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The operations and associated PDU formats is described in RFC 1905
second version, called SMIv2, is described in RFC 1902 [RFC1902], [RFC1905].
RFC 1903 [RFC1903] and RFC 1904 [RFC1904].
o Message protocols for transferring management information. The o A set of fundamental applications described in RFC 2573 [RFC2573]
first version of the SNMP message protocol is called SNMPv1 and and the view-based access control mechanism described in RFC 2575
described in RFC 1157 [RFC1157]. A second version of the SNMP [RFC2575].
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 2272
[RFC2272] and RFC 2274 [RFC2274].
o Protocol operations for accessing management information. The first A more detailed introduction to the current SNMP Management Framework
set of protocol operations and associated PDU formats is described can be found in RFC 2570 [RFC2570].
in RFC 1157 [RFC1157]. A second set of protocol operations and
associated PDU formats is described in RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2273 [RFC2273] Managed objects are accessed via a virtual information store, termed
and the view-based access control mechanism described in RFC 2275 the Management Information Base or MIB. Objects in the MIB are
[RFC2275]. defined using the mechanisms defined in the SMI.
Managed objects are accessed via a virtual information store, termed the This memo does not specify a MIB module.
Management Information Base or MIB. Objects in the MIB are defined
using the mechanisms defined in the SMI.
This memo does not specify a MIB module. 2. Overview
5. Overview The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs
to globally identify individual protocol encapsulations in the
protocolDirTable.
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to This guide contains algorithms and the authoritative set of base
globally identify individual protocol encapsulations in the layer protocol identifier macros, for use within INDEX values in the
protocolDirTable. protocolDirTable.
This guide contains algorithms and the authoritative set of base layer This is the second revision of this document, and is intended to
protocol identifier macros, for use within INDEX values in the replace the first half of the first RMON-2 Protocol Identifiers
protocolDirTable. document. [RFC2074].
This is the the second revision of this document, and is intended to 2.1. Terms
replace the first half the RMON-2 Protocol Identifiers document
[RFC2074].
5.1. Terms 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].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Several terms are used throughout this document, as well as in the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this RMON-2 MIB [RFC2021], that should be introduced:
document are to be interpreted as described in RFC 2119 [RFC2119].
Several terms are used throughout this document, as well as in the parent protocol:
RMON-2 MIB [RFC2021], that should be introduced: 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.
parent protocol: child protocol:
Also called 'parent'; The encapsulating protocol identifier for a Also called 'child'; An encapsulated protocol identifier for a
specific protocol layer, e.g., IP is the parent protocol of UDP. specific protocol layer. e.g., UDP is a child protocol of IP.
Note that base layers cannot have parent protocols. This term may This term may be used to refer to a specific encapsulated
be used to refer to a specific encapsulating protocol, or it may be protocol, or it may be used generically to refer to any
used generically to refer to any encapsulating protocol. encapsulated protocol.
child protocol: layer-identifier:
Also called 'child'; An encapsulated protocol identifier for a An octet string fragment representing a particular protocol
specific protocol layer. e.g., UDP is a child protocol of IP. This encapsulation layer or sub-layer. A fragment consists of
term may be used to refer to a specific encapsulated protocol, or exactly four octets, encoded in network byte order. If present,
it may be used generically to refer to any encapsulated protocol. child layer-identifiers for a protocol MUST have unique values
among each other. (See section 3.3 for more details.)
layer-identifier: protocol:
An octet string fragment representing a particular protocol A particular protocol layer, as specified by encoding rules in
encapsulation layer or sub-layer. A fragment consists of exactly this document. Usually refers to a single layer in a given
four octets, encoded in network byte order. If present, child encapsulation. Note that this term is sometimes used in the
layer-identifiers for a protocol MUST have unique values among each RMON-2 MIB [RFC2021] to name a fully-specified protocol-
other. (See section 6.3 for more details.) 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.
protocol: protocol-identifier string:
A particular protocol layer, as specified by encoding rules in this An octet string representing a particular protocol
document. Usually refers to a single layer in a given encapsulation, as specified by the encoding rules in this
encapsulation. Note that this term is sometimes used in the RMON-2 document. This string is identified in the RMON-2 MIB [RFC2021]
MIB [RFC2021] to name a fully-specified protocol-identifier string. as the protocolDirID object. A protocol-identifier string is
In such a case, the protocol-identifier string is named for its composed of one or more layer-identifiers read from left to
upper-most layer. A named protocol may also refer to any right. The left-most layer-identifier specifies a base layer
encapsulation of that protocol. encapsulation. Each layer-identifier to the right specifies a
child layer protocol encapsulation.
protocol-identifier string: protocol-identifier macro: Also called a PI macro; A macro-like
An octet string representing a particular protocol encapsulation, textual construct used to describe a particular networking
as specified by the encoding rules in this document. This string is protocol. Only protocol attributes which are important for RMON
identified in the RMON-2 MIB [RFC2021] as the protocolDirID object. use are documented. Note that the term 'macro' is historical,
A protocol-identifier string is composed of one or more layer- and PI macros are not real macros, nor are they ASN.1 macros.
identifiers read from left to right. The left-most layer-identifier The current set of published RMON PI macros can be found in the
specifies a base layer encapsulation. Each layer-identifier to the RMON Protocol Identifier Macros document [RFC2896].
right specifies a child layer protocol encapsulation.
protocol-identifier macro: The PI macro serves several purposes:
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
[RMONPROT_MAC].
The PI macro serves several purposes: - 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.
- Names the protocol for use within the RMON-2 MIB [RFC2021]. protocol-variant-identifier macro:
- Describes how the protocol is encoded into an octet string. Also called a PI-variant macro; A special kind of PI macro, used
- Describes how child protocols are identified (if applicable), to describe a particular protocol layer, which cannot be
and encoded into an octet string. identified with a deterministic, and (usually) hierarchical
- Describes which protocolDirParameters are allowed for the protocol. structure, like most networking protocols.
- Describes how the associated protocolDirType object is encoded
for the protocol.
- Provides reference(s) to authoritative documentation for the
protocol.
protocol-variant-identifier macro: Note that the PI-variant macro and the PI-macro are defined with
Also called a PI-variant macro; A special kind of PI macro, used to a single set of syntax rules (see section 3.2), except that
describe a particular protocol layer, which cannot be identified different sub-clauses are required for each type.
with a deterministic, and (usually) hierarchical structure, like
most networking protocols.
Note that the PI-variant macro and the PI-macro are defined with a A protocol identified with a PI-variant macro is actually a
single set of syntax rules (see section 6.2), except that different variant of a well known encapsulation that may be present in the
sub-clauses are required for each type. protocolDirTable. This is used to document the IANA assigned
protocols, which are needed to identify protocols which cannot
be practically identified by examination of 'appropriate network
traffic' (e.g. the packets which carry them). All other
protocols (which can be identified by examination of appropriate
network traffic) SHOULD be documented using the protocol-
identifier macro. (See section 3.2 for details.)
A protocol identified with a PI-variant macro is actually a variant protocol-parameter:
of a well known encapsulation that may be present in the A single octet, corresponding to a specific layer-identifier in
protocolDirTable. This is used to document the IANA assigned the protocol-identifier. This octet is a bit-mask indicating
protocols, which are needed to identify protocols which cannot be special functions or capabilities that this agent is providing
practically identified by examination of 'appropriate network for the corresponding protocol. (See section 3.2.6 for
traffic' (e.g. the packets which carry them). All other protocols details.)
(which can be identified by examination of appropriate network
traffic) SHOULD be documented using the protocol-identifier macro.
(See section 6.2 for details.)
protocol-parameter: protocol-parameters string:
A single octet, corresponding to a specific layer-identifier in the An octet string, which contains one protocol-parameter for each
protocol-identifier. This octet is a bit-mask indicating special layer-identifier in the protocol-identifier. This string is
functions or capabilities that this agent is providing for the identified in the RMON-2 MIB [RFC2021] as the
corresponding protocol. (See section 6.2.6 for details.) protocolDirParameters object. (See the section 3.2.6 for
details.)
protocol-parameters string: protocolDirTable INDEX:
An octet string, which contains one protocol-parameter for each A protocol-identifier and protocol-parameters octet string pair
layer-identifier in the protocol-identifier. This string is that have been converted to an INDEX value, according to the
identified in the RMON-2 MIB [RFC2021] as the protocolDirParameters encoding rules in section 7.7 of RFC 1902 [RFC1902].
object. (See the section 6.2.6 for details.)
protocolDirTable INDEX: pseudo-protocol:
A protocol-identifier and protocol-parameters octet string pair A convention or algorithm used only within this document for the
that have been converted to an INDEX value, according to the purpose of encoding protocol-identifier strings.
encoding rules in in section 7.7 of RFC 1902 [RFC1902].
pseudo-protocol: protocol encapsulation tree:
A convention or algorithm used only within this document for the Protocol encapsulations can be organized into an inverted tree.
purpose of encoding protocol-identifier strings. 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.
protocol encapsulation tree: 2.2. Relationship to the Remote Network Monitoring MIB
Protocol encapsulations can be organized into an inverted rooted
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.
5.2. Relationship to the Remote Network Monitoring MIB This document is intended to identify the encoding rules for the
OCTET STRING objects protocolDirID and protocolDirParameters. RMON-2
tables, such as those in the new Protocol Distribution, Host, and
Matrix groups, use a local INTEGER INDEX (protocolDirLocalIndex)
rather than complete protocolDirTable INDEX strings, to identify
protocols for counting purposes. Only the protocolDirTable uses the
protocolDirID and protocolDirParameters strings described in this
document.
This document is intended to identify the encoding rules for the OCTET This document is intentionally separated from the RMON-2 MIB objects
STRING objects protocolDirID and protocolDirParameters. RMON-2 tables, [RFC2021] to allow updates to this document without any republication
such as those in the new Protocol Distribution, Host, and Matrix groups, of MIB objects.
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.
This document is intentionally separated from the RMON-2 MIB objects This document does not discuss auto-discovery and auto-population of
[RFC2021] to allow updates to this document without any republication of the protocolDirTable. This functionality is not explicitly defined by
MIB objects. the RMON standard. An agent SHOULD populate the directory with the
'interesting' protocols on which the intended applications depend.
This document does not discuss auto-discovery and auto-population of the 2.3. Relationship to the RMON Protocol Identifier Macros Document
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.
5.3. Relationship to the RMON Protocol Identifier Macros Document The original RMON Protocol Identifiers document [RFC2074] contains
the protocol directory reference material, as well as many examples
of protocol identifier macros.
The original RMON Protocol Identifiers document [RFC2074] contains the These macros have been moved to a separate document called the RMON
protocol directory reference material, as well as many examples of Protocol Identifier Macros document [RFC2896]. This will allow the
protocol identifier macros. 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.
These macros have been moved to a separate document called the RMON The PI Macros document is intentionally separated from this document
Protocol Identifier Macros document [RMONPROT_MAC]. This will allow the to allow updates to the list of published PI macros without any
normative text (this document) to advance on the standards track with republication of MIB objects or encoding rules. Protocol Identifier
the RMON-2 MIB [RFC2021], while the collection of PI macros is macros submitted from the RMON working group and community at large
maintained in an Informational RFC. (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.
The PI Macros document is intentionally separated from this document to Macros submissions will be collected in the IANA's MIB files under
allow frequent updates to the list of published PI macros without any the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in
republication of MIB objects or encoding rules. Protocol Identifier the RMONMIB working group mailing list message archive file
macros submitted from the RMON working group and community at large (to www.ietf.org/mail-archive/working-
the RMONMIB WG mailing list at 'rmonmib@cisco.com') will be collected, groups/rmonmib/current/maillist.htm.
screened by the RMONMIB working group, and (if approved) added to a
subsequent version of the PI Macros document.
Macros submissions will be collected in the IANA's MIB files under the 2.4. Relationship to the ATM-RMON MIB
directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the
RMONMIB working group mailing list message archive file
"ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib".
5.4. Relationship to the ATM-RMON MIB The ATM Forum has standardized "Remote Monitoring MIB Extensions for
ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides
RMON-like stats, host, matrix, and matrixTopN capability for NSAP
address-based (ATM Adaption Layer 5, AAL-5) cell traffic.
The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM 2.4.1. Port Aggregation
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.
5.4.1. Port Aggregation 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.
It it possible to correlate ATM-RMON MIB data with packet-based RMON-2 2.4.2. Encapsulation Mappings
[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.
5.4.2. Encapsulation Mappings 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.
The RMON PI document does not contain explicit PI macro support for An NMS can determine some of the omitted encapsulation details by
"Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or examining the interface type (ifType) of the dataSource for a
ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, particular RMON collection:
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 6.2 for details on
identifying and decoding a particular base layer.
An NMS can determine some of the omitted encapsulation details by RFC 1483 dataSource ifTypes:
examining the interface type (ifType) of the dataSource for a particular - aal5(49)
RMON collection:
RFC 1483 dataSource ifTypes: LANE dataSource ifTypes:
- aal5(49) - aflane8023(59)
- aflane8025(60)
LANE dataSource ifTypes: These dataSources require implementation of the ifStackTable from the
- aflane8023(59) Interfaces MIB [RFC2233]. It is possible that some implementations
- aflane8025(60) 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.
These dataSources require implementation of the ifStackTable from the 2.4.3. Counting ATM Traffic in RMON-2 Collections
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.
5.4.3. Counting ATM Traffic in RMON-2 Collections 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.
The RMON-2 Application Layer (AL) and Network Layer (NL) Probe implementations must use the AAL-5 frame size (not the AAL-5
(host/matrix/topN) tables require that octet counters be incremented by payload size or encapsulated MAC frame size) as the 'frame size' for
the size of the particular frame, not by the size of the frame the purpose of incrementing RMON-2 octet counters (e.g.,
attributed to a given protocol. 'nlHostInOctets', 'alHostOutOctets').
Probe implementations must use the AAL-5 frame size (not the AAL-5 The RMONMIB WG has not addressed issues relating to packet capture of
payload size or encapsulated MAC frame size) as the 'frame size' for the AAL-5 based traffic. Therefore, it is an implementation-specific
purpose of incrementing RMON-2 octet counters (e.g., 'nlHostInOctets', matter whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3
'alHostOutOctets'). 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).
The RMONMIB WG has not addressed issues relating to packet capture of 2.5. Relationship to Other MIBs
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).
5.5. Relationship to Other MIBs The RMON Protocol Identifiers Reference document is intended for use
with the protocolDirTable within the RMON MIB. It is not relevant to
any other MIB, or intended for use with any other MIB.
The RMON Protocol Identifiers Reference document is intended for use 3. Protocol Identifier Encoding
with the protocolDirTable within the RMON MIB. It is not relevant to any
other MIB, or intended for use with any other MIB.
6. Protocol Identifier Encoding 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.)
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and The first OCTET STRING (protocolDirID) is composed of one or more 4-
protocolDirParameters. To encode the table index, each variable-length octet "layer-identifiers". The entire string uniquely identifies a
string is converted to an OBJECT IDENTIFIER fragment, according to the particular node in the protocol encapsulation tree. The second OCTET
encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index STRING, (protocolDirParameters) which contains a corresponding number
fragments are simply concatenated. (Refer to figures 1a - 1d below for of 1-octet protocol-specific parameters, one for each 4-octet layer-
more detail.) identifier in the first string.
The first OCTET STRING (protocolDirID) is composed of one or more 4- A protocol layer is normally identified by a single 32-bit value.
octet "layer-identifiers". The entire string uniquely identifies a Each layer-identifier is encoded in the ProtocolDirID OCTET STRING
particular node in the protocol encapsulation tree. The second OCTET INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent
STRING, (protocolDirParameters) which contains a corresponding number of each byte of the 32-bit value in network byte order. If a particular
1-octet protocol-specific parameters, one for each 4-octet layer- protocol layer cannot be encoded into 32 bits, then it must be
identifier in the first string. defined as an 'ianaAssigned' protocol (see below for details on IANA
assigned protocols).
A protocol layer is normally identified by a single 32-bit value. Each The following figures show the differences between the OBJECT
layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as IDENTIFIER and OCTET STRING encoding of the protocol identifier
four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of string.
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).
The following figures show the differences between the OBJECT IDENTIFIER Fig. 1a
and OCTET STRING encoding of the protocol identifier string. protocolDirTable INDEX Format
-----------------------------
Fig. 1a +---+--------------------------+---+---------------+
protocolDirTable INDEX Format | c ! | c ! protocolDir |
----------------------------- | n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
+---+--------------------------+---+---------------+ protocolDirID
| c ! | c ! protocolDir | +----------------------------------------+
| n ! protocolDirID | n ! Parameters | | |
| t ! | t ! | | 4 * N octets |
+---+--------------------------+---+---------------+ | |
+----------------------------------------+
Fig. 1b protocolDirParameters
protocolDirTable OCTET STRING Format +----------+
------------------------------------ | |
| N octets |
| |
+----------+
protocolDirID 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
| 4 * N octets | a network layer protocol, but this is not always the case,
| | (most notably for children of the 'vsnap' base-layer).
+----------------------------------------+
protocolDirParameters Fig. 1c
+----------+ protocolDirTable INDEX Format Example
| | -------------------------------------
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers required protocolDirID protocolDirParameters
for the entire encapsulation of the named protocol. Note +---+--------+--------+--------+--------+---+---+---+---+---+
that the layer following the base layer usually identifies | c | proto | proto | proto | proto | c |par|par|par|par|
a network layer protocol, but this is not always the case, | n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
(most notably for children of the 'vsnap' base-layer). | t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
Fig. 1c When encoded in a protocolDirTable INDEX, each of the two
protocolDirTable INDEX Format Example 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'.
protocolDirID protocolDirParameters Fig. 1d
+---+--------+--------+--------+--------+---+---+---+---+---+ protocolDirTable OCTET STRING Format Example
| 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 protocolDirID
strings must be preceded by a length sub-component. In this +--------+--------+--------+--------+
example, N equals '4', the first 'cnt' field would contain | proto | proto | proto | proto |
the value '16', and the second 'cnt' field would contain | base | L3 | L4 | L5 |
the value '4'. | | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
Fig. 1d protocolDirParameters
protocolDirTable OCTET STRING Format Example +---+---+---+---+
-------------------------------------------- |par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
protocolDirID Although this example indicates four encapsulated protocols, in
+--------+--------+--------+--------+ practice, any non-zero number of layer-identifiers may be present,
| proto | proto | proto | proto | theoretically limited only by OBJECT IDENTIFIER length restrictions,
| base | L3 | L4 | L5 | as specified in section 3.5 of RFC 1902 [RFC1902].
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters 3.1. ProtocolDirTable INDEX Format Examples
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
Although this example indicates four encapsulated protocols, in The following PI identifier fragments are examples of some fully
practice, any non-zero number of layer-identifiers may be present, encoded protocolDirTable INDEX values for various encapsulations.
theoretically limited only by OBJECT IDENTIFIER length restrictions, as
specified in section 3.5 of RFC 1902 [RFC1902].
Note that these two strings would not be concatenated together if ever -- HTTP; fragments counted from IP and above
returned in a GetResponse PDU, since they are different MIB objects. ether2.ip.tcp.www-http =
However, protocolDirID and protocolDirParameters are not currently 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
readable MIB objects.
6.1. ProtocolDirTable INDEX Format Examples -- 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
The following PI identifier fragments are examples of some fully encoded -- SNMP over IPX over SNAP
protocolDirTable INDEX values for various encapsulations. snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- HTTP; fragments counted from IP and above -- SNMP over IPX over raw8023
ether2.ip.tcp.www-http = ianaAssigned.ipxOverRaw8023.snmp =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0 12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- SNMP over UDP/IP over SNAP -- IPX over LLC
snap.ip.udp.snmp = llc.ipx =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over IPX over SNAP -- SNMP over UDP/IP over any link layer
snap.ipx.snmp = ether2.ip.udp.snmp
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over raw8023 -- IP over any link layer; base encoding is IP over ether2
ianaAssigned.ipxOverRaw8023.snmp = ether2.ip
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0 8.1.0.0.1.0.0.8.0.2.0.0
-- IPX over LLC -- AppleTalk Phase 2 over ether2
llc.ipx = ether2.atalk
8.0.0.0.2.0.0.0.224.2.0.0 8.0.0.0.1.0.0.128.155.2.0.0
-- SNMP over UDP/IP over any link layer -- AppleTalk Phase 2 over vsnap
ether2.ip.udp.snmp vsnap.apple-oui.atalk
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
-- IP over any link layer; base encoding is IP over ether2 3.2. Protocol Identifier Macro Format
ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether2 The following example is meant to introduce the protocol-identifier
ether2.atalk macro. This macro-like construct is used to represent both protocols
8.0.0.0.1.0.0.128.155.2.0.0 and protocol-variants.
-- AppleTalk Phase 2 over vsnap If the 'VariantOfPart' component of the macro is present, then the
vsnap.apple-oui.atalk macro represents a protocol-variant instead of a protocol. This
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0 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.
6.2. Protocol Identifier Macro Format 3.2.1. Lexical Conventions
The following example is meant to introduce the protocol-identifier The PI language defines the following keywords:
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 ADDRESS-FORMAT
represents a protocol-variant instead of a protocol. This clause is ATTRIBUTES
currently used only for IANA assigned protocols, enumerated under the CHILDREN
'ianaAssigned' base-layer. The VariantOfPart component MUST be present DECODING
for IANA assigned protocols. DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
6.2.1. Lexical Conventions The PI language defines the following punctuation elements:
The PI language defines the following keywords: { left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
ADDRESS-FORMAT 3.2.2. Notation for Syntax Descriptions
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
The PI language defines the following punctuation elements: 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:
{ left curly brace * Literal values are specified in quotes, for example "REFERENCE"
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
6.2.2. Notation for Syntax Descriptions * Non-terminal items are surrounded by less than (<) and greater
than (>) characters, for example <parmList>
An extended form of the BNF notation is used to specify the syntax of * Terminal items are specified without surrounding quotes or less
the PI language. The rules for this notation are shown below: than and greater than characters, for example 'lcname'
* Literal values are specified in quotes, for example "REFERENCE" * A vertical bar (|) is used to indicate a choice between items,
for example 'number | hstr'
* Replaceable items are surrounded by less than (<) and greater than * Ellipsis are used to indicate that the previous item may be
(>) characters, for example <parmList> repeated one or more times, for example <parm>...
* Defined items are specified without surrounding quotes or less than * Square brackets are used to enclose optional items, for example
and greater than characters, for example 'lcname' [ "," <parm> ]
* A vertical bar (|) is used to indicate a choice between items, for * An equals character (=) is used to mean "defined as," for
example 'number | hstr' example '<protoName> = pname'
* Ellipsis are used to indicate that the previous item may be 3.2.3. Grammar for the PI Language
repeated one or more times, for example <parm>...
* Square brackets are used to enclose optional items, for example [ The following are "terminals" of the grammar and are identical to the
"," <parm> ] same lexical elements from the MIB module language, except for hstr
and pname:
* An equals character (=) is used to mean "defined as," for example <lc> = "a" | "b" | "c" | ... | "z"
'<protoName> = pname' <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> ]
6.2.3. Grammar for the PI Language <pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
The following are "defined items" or "terminals" of the grammar and are <number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
identical to the same lexical elements from the MIB module language,
except for hstr and pname:
lcname - name starting with a lower-case letter, and may contain
letters, digits, and dash characters (-)
pname - name starting with a letter or digit, and may contain
letters, digits, dashes (-), underbars (_), asterisks (*),
and pluses (+) (See section 6.2.4)
number - an unsigned decimal number between 0 and 4g-1
hstr - an unsigned hexadecimal number between 0 and 4g-1
(note: the format is that used in the ANSI C programming
language. For example, 0x04 has the value of 4.)
string - a quoted string
The following is the extended BNF notation for the grammar with starting <hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
symbol <piFile>: <hrest> = <hdigit> [ <hrest> ]
-- a file containing one or more Protocol Identifier (PI) definitions <lf> = linefeed char
<piFile> = <piDefinition>... <cr> = carriage return char
<eoln> = <cr><lf> | <lf>
-- a PI definition <sp> = " "
<piDefinition> = <tab> = " "
<protoName> "PROTOCOL-IDENTIFIER" <wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name <string> = """ [ <strest> ] """
<protoName> = pname <strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
-- a list of parameters The following is the extended BNF notation for the grammar with
<parmList> = <parm> [ "," <parm> ]... starting symbol <piFile>:
-- a parameter -- a file containing one or more Protocol Identifier (PI)
<parm> = lcname "(" <nonNegNum> ")" -- definitions
<piFile> = <piDefinition>...
-- list of attributes -- a PI definition
<attrList> = <attr> [ "," <attr> ]... <piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- an attribute -- a protocol name
<attr> = lcname "(" <nonNegNum> ")" <protoName> = pname
-- a non-negative number -- a list of parameters
<nonNegNum> = number | hstr <parmList> = <parm> [ "," <parm> ]...
-- list of encapsulation values -- a parameter
<encapList> = <encapValue> [ "," <encapValue> ]... <parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- an encapsulation value -- list of attributes
<encapValue> = <baseEncapValue> | <normalEncapValue> <attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- base encapsulation value -- an attribute
<baseEncapValue> = <nonNegNum> <attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- normal encapsulation value -- a non-negative number
<normalEncapValue> = <protoName> <nonNegNum> <nonNegNum> = number | hstr
-- comment -- list of encapsulation values
<two dashes> <text> <end-of-line> <encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
6.2.4. Mapping of the Protocol Name -- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
The "protoName" value, called the "protocol name" shall be an ASCII -- base encapsulation value
string consisting of one up to 64 characters from the following: <baseEncapValue> = <nonNegNum>
"A" through "Z" -- normal encapsulation value
"a" through "z" <normalEncapValue> = <protoName> <wspace> <nonNegNum>
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
plus(+)
The first character of the protocol name is limited to one of the -- comment
following: <two dashes> <text> <end-of-line>
"A" through "Z" 3.2.4. Mapping of the Protocol Name
"a" through "z"
"0" through "9"
This value SHOULD be the name or acronym identifying the protocol. Note The "protoName" value, called the "protocol name" shall be an ASCII
that case is significant. The value selected for the protocol name string consisting of one up to 64 characters from the following:
SHOULD match the "most well-known" name or acronym for the indicated
protocol. For example, the document indicated by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers "A" through "Z"
"a" through "z"
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
plus(+)
defines IP Protocol field values, so protocol-identifier macros for The first character of the protocol name is limited to one of the
children of IP SHOULD be given names consistent with the protocol names following:
found in this authoritative document. Likewise, children of UDP and TCP
SHOULD be given names consistent with the port number name assignments
found in:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers "A" through "Z"
"a" through "z"
"0" through "9"
When the "well-known name" contains characters not allowed in protocol This value SHOULD be the name or acronym identifying the protocol.
names, they MUST be changed to a dash character ("-") . In the event Note that case is significant. The value selected for the protocol
that the first character must be changed, the protocol name is prepended name SHOULD match the "most well-known" name or acronym for the
with the letter "p", so the former first letter may be changed to a indicated protocol. For example, the document indicated by the URL:
dash.
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
following protocol names are legal:
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu 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:
Note that it is possible in actual implementation that different ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
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.
6.2.5. Mapping of the VARIANT-OF Clause 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.
This clause is present for IANA assigned protocols only. It identifies For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The
the protocol-identifier macro that most closely represents this following protocol names are legal:
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'.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol- ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
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 Note that it is possible in actual implementation that different
protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e. encapsulations of the same protocol (which are represented by
"PARAMETERS {}") MUST be present in a protocol-variant-identifier macro, different entries in the protocolDirTable) will be assigned the same
and the 'ParamList' and 'AttrList' found in the reference protocol- protocol name. The protocolDirID INDEX value defines a particular
identifier macro examined instead. protocol, not the protocol name string.
Note that if an 'ianaAssigned' protocol is defined that is not a variant 3.2.5. Mapping of the VARIANT-OF Clause
of any other documented protocol, then the protocol-identifier macro
SHOULD be used instead of the protocol-variant-identifier version of the
macro.
6.2.6. Mapping of the PARAMETERS Clause 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'.
The protocolDirParameters object provides an NMS the ability to turn on Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference
and off expensive probe resources. An agent may support a given protocol-identifier macro SHOULD NOT be duplicated in the protocol-
parameter all the time, not at all, or subject to current resource load. variant-identifier macro, if the 'variant' protocols' semantics are
identical for a given clause.
The PARAMETERS clause is a list of bit definitions which can be directly Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a
encoded into the associated ProtocolDirParameters octet in network byte protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e.
order. Zero or more bit definitions may be present. Only bits 0-7 are "PARAMETERS {}") MUST be present in a protocol-variant-identifier
valid encoding values. This clause defines the entire BIT set allowed macro, and the 'ParamList' and 'AttrList' found in the reference
for a given protocol. A conforming agent may choose to implement a protocol-identifier macro examined instead.
subset of zero or more of these PARAMETERS.
By convention, the following common bit definitions are used by Note that if an 'ianaAssigned' protocol is defined that is not a
different protocols. These bit positions MUST NOT be used for other variant of any other documented protocol, then the protocol-
parameters. They MUST be reserved if not used by a given protocol. identifier macro SHOULD be used instead of the protocol-variant-
identifier version of the macro.
Bits are encoded in a single octet. Bit 0 is the high order (left-most) 3.2.6. Mapping of the PARAMETERS Clause
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.
Table 3.1 Reserved PARAMETERS Bits 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.
Bit Name Description The PARAMETERS clause is a list of bit definitions which can be
--------------------------------------------------------------------- directly encoded into the associated ProtocolDirParameters octet in
0 countsFragments higher-layer protocols encapsulated within network byte order. Zero or more bit definitions may be present. Only
this protocol will be counted correctly even bits 0-7 are valid encoding values. This clause defines the entire
if this protocol fragments the upper layers BIT set allowed for a given protocol. A conforming agent may choose
into multiple packets. to implement a subset of zero or more of these PARAMETERS.
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 By convention, the following common bit definitions are used by
declarations, but may be equal to zero (empty). different protocols. These bit positions MUST NOT be used for other
parameters. They MUST be reserved if not used by a given protocol.
6.2.6.1. Mapping of the 'countsFragments(0)' BIT 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.
This bit indicates whether the probe is correctly attributing all Table 3.1 Reserved PARAMETERS Bits
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.
This bit MUST only be set in a protocolDirParameters octet which Bit Name Description
corresponds to a protocol that supports fragmentation and reassembly in ---------------------------------------------------------------------
some form. Note that TCP packets are not considered 'fragmented-streams' 0 countsFragments higher-layer protocols encapsulated within
and so TCP is not eligible. 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).
This bit may be set in at most one protocolDirParameters octet within a The PARAMETERS clause MUST be present in all protocol-identifier
protocolDirTable INDEX. macro declarations, but may be equal to zero (empty).
6.2.6.2. Mapping of the 'tracksSessions(1)' BIT 3.2.6.1. Mapping of the 'countsFragments(0)' BIT
The 'tracksSessions(1)' bit indicates whether frames which are part of This bit indicates whether the probe is correctly attributing all
remapped-sessions (e.g. TFTP download sessions) are correctly counted by fragmented packets of the specified protocol, even if individual
the probe. For such a protocol, the probe must usually analyze all frames carrying this protocol cannot be identified as such. Note
packets received on the indicated interface, and maintain some state that the probe is not required to actually present any re-assembled
information, (e.g. the remapped UDP port number for TFTP). datagrams (for address-analysis, filtering, or any other purpose) to
the NMS.
The semantics of the 'tracksSessions' parameter are independent of the This bit MUST only be set in a protocolDirParameters octet which
other protocolDirParameters definitions, so this parameter MAY be corresponds to a protocol that supports fragmentation and reassembly
combined with any other legal parameter configurations. in some form. Note that TCP packets are not considered 'fragmented-
streams' and so TCP is not eligible.
6.2.7. Mapping of the ATTRIBUTES Clause This bit MAY be set in more than one protocolDirParameters octet
within a protocolDirTable INDEX, in the event an agent can count
fragments at more than one protocol layer.
The protocolDirType object provides an NMS with an indication of a 3.2.6.2. Mapping of the 'tracksSessions(1)' BIT
probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol.
The ATTRIBUTES clause is a list of bit definitions which are encoded The 'tracksSessions(1)' bit indicates whether frames which are part
into the associated instance of ProtocolDirType. The BIT definitions are of remapped sessions (e.g. TFTP download sessions) are correctly
specified in the SYNTAX clause of the protocolDirType MIB object. 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).
Table 3.2 Reserved ATTRIBUTES Bits 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.
Bit Name Description 3.2.7. Mapping of the ATTRIBUTES Clause
---------------------------------------------------------------------
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 The protocolDirType object provides an NMS with an indication of a
declarations, but MAY be empty. probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol.
6.2.8. Mapping of the DESCRIPTION Clause 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.
The DESCRIPTION clause provides a textual description of the protocol Table 3.2 Reserved ATTRIBUTES Bits
identified by this macro. Notice that it SHOULD NOT contain details ------------------------------------
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
REFERENCE clauses.
The DESCRIPTION clause MUST be present in all protocol-identifier macro Bit Name Description
declarations. ---------------------------------------------------------------------
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.
6.2.9. Mapping of the CHILDREN Clause The ATTRIBUTES clause MUST be present in all protocol-identifier
macro declarations, but MAY be empty.
The CHILDREN clause provides a description of child protocols for 3.2.8. Mapping of the DESCRIPTION Clause
protocols which support them. It has three sub-sections:
The DESCRIPTION clause provides a textual description of the protocol
identified by this macro. Notice that it SHOULD NOT contain details
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
REFERENCE clauses.
The DESCRIPTION clause MUST be present in all protocol-identifier
macro declarations.
3.2.9. Mapping of the CHILDREN Clause
The CHILDREN clause provides a description of child protocols for
protocols which support them. It has three sub-sections:
- Details on the field(s)/value(s) used to select the child protocol, - Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed and how that selection process is performed
- Details on how the value(s) are encoded in the protocol identifier - Details on how the value(s) are encoded in the protocol identifier
octet string octet string
- Details on how child protocols are named with respect to their - Details on how child protocols are named with respect to their
parent protocol label(s) parent protocol label(s)
The CHILDREN clause MUST be present in all protocol-identifier macro The CHILDREN clause MUST be present in all protocol-identifier macro
declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES declarations in which the 'hasChildren(0)' BIT is set in the
clause. ATTRIBUTES clause.
6.2.10. Mapping of the ADDRESS-FORMAT Clause 3.2.10. Mapping of the ADDRESS-FORMAT Clause
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
format(s) used when encoding addresses. format(s) used when encoding addresses.
This clause MUST be present in all protocol-identifier macro This clause MUST be present in all protocol-identifier macro
declarations in which the 'addressRecognitionCapable(1)' BIT is set in declarations in which the 'addressRecognitionCapable(1)' BIT is set
the ATTRIBUTES clause. in the ATTRIBUTES clause.
6.2.11. Mapping of the DECODING Clause 3.2.11. Mapping of the DECODING Clause
The DECODING clause provides a description of the decoding procedure for The DECODING clause provides a description of the decoding procedure
the specified protocol. It contains useful decoding hints for the for the specified protocol. It contains useful decoding hints for the
implementor, but SHOULD NOT over-replicate information in documents implementor, but SHOULD NOT over-replicate information in documents
cited in the REFERENCE clause. It might contain a complete description cited in the REFERENCE clause. It might contain a complete
of any decoding information required. description of any decoding information required.
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection as offset and type information for the field(s) used for child selection
well as information on determining the start of the child protocol. as well as information on determining the start of the child
protocol.
For 'addressRecognitionCapable' protocols this includes offset and type For 'addressRecognitionCapable' protocols this includes offset and
information for the field(s) used to generate addresses. type information for the field(s) used to generate addresses.
The DECODING clause is optional, and MAY be omitted if the REFERENCE The DECODING clause is optional, and MAY be omitted if the REFERENCE
clause contains pointers to decoding information for the specified clause contains pointers to decoding information for the specified
protocol. protocol.
6.2.12. Mapping of the REFERENCE Clause 3.2.12. Mapping of the REFERENCE Clause
If a publicly available reference document exists for this protocol it If a publicly available reference document exists for this protocol
SHOULD be listed here. Typically this will be a URL if possible; if not it SHOULD be listed here. Typically this will be a URL if possible;
then it will be the name and address of the controlling body. if not then it will be the name and address of the controlling body.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the
amount of information which may currently be obtained from an amount of information which may currently be obtained from an
authoritative document, such as the Assigned Numbers document [RFC1700]. authoritative document, such as the Assigned Numbers document
Any duplication or paraphrasing of information should be brief and [RFC1700]. Any duplication or paraphrasing of information should be
consistent with the authoritative document. brief and consistent with the authoritative document.
The REFERENCE clause is optional, but SHOULD be implemented if an The REFERENCE clause is optional, but SHOULD be implemented if an
authoritative reference exists for the protocol (especially for standard authoritative reference exists for the protocol (especially for
protocols). standard protocols).
6.3. Evaluating an Index of the ProtocolDirectoryTable 3.3. Evaluating an Index of the ProtocolDirTable
The following evaluation is done after protocolDirTable INDEX value has The following evaluation is done after a protocolDirTable INDEX value
been converted into two OCTET STRINGs according to the INDEX encoding has been converted into two OCTET STRINGs according to the INDEX
rules specified in the SMI [RFC1902]. encoding rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the Protocol-identifiers are evaluated left to right, starting with the
protocolDirID, which length MUST be evenly divisible by four. The protocolDirID, which length MUST be evenly divisible by four. The
protocolDirParameters length MUST be exactly one quarter of the protocolDirParameters length MUST be exactly one quarter of the
protocolDirID string length. protocolDirID string length.
Protocol-identifier parsing starts with the base layer identifier, which Protocol-identifier parsing starts with the base layer identifier,
MUST be present, and continues for one or more upper layer identifiers, which MUST be present, and continues for one or more upper layer
until all OCTETs of the protocolDirID have been used. Layers MAY NOT be identifiers, until all OCTETs of the protocolDirID have been used.
skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can Layers MUST NOT be skipped, so identifiers such as 'SNMP over IP' or
not exist. 'TCP over ether2' can not exist.
The base-layer-identifier also contains a 'special function identifier' The base-layer-identifier also contains a 'special function
which may apply to the rest of the protocol identifier. identifier' which may apply to the rest of the protocol identifier.
Wild-carding at the base layer within a protocol encapsulation is the Wild-carding at the base layer within a protocol encapsulation is the
only supported special function at this time. (See section 7.1.1.2 for only supported special function at this time. (See section 4.1.1.2
details.) for details.)
After the protocol-identifier string (which is the value of After the protocol-identifier string (which is the value of
protocolDirID) has been parsed, each octet of the protocol-parameters protocolDirID) has been parsed, each octet of the protocol-parameters
string is evaluated, and applied to the corresponding protocol layer. string is evaluated, and applied to the corresponding protocol layer.
A protocol-identifier label MAY map to more than one value. For A protocol-identifier label MAY map to more than one value. For
instance, 'ip' maps to 5 distinct values, one for each supported instance, 'ip' maps to 5 distinct values, one for each supported
encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers' in encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'
the RMON Protocol Identifier Macros document [RMONPROT_MAC]). in the RMON Protocol Identifier Macros document [RFC2896]).
It is important to note that these macros are conceptually expanded at It is important to note that these macros are conceptually expanded
implementation time, not at run time. at implementation time, not at run time.
If all the macros are expanded completely by substituting all possible If all the macros are expanded completely by substituting all
values of each label for each child protocol, a list of all possible possible values of each label for each child protocol, a list of all
protocol-identifiers is produced. So 'ip' would result in 5 distinct possible protocol-identifiers is produced. So 'ip' would result in 5
protocol-identifiers. Likewise each child of 'ip' would map to at least distinct protocol-identifiers. Likewise each child of 'ip' would map
5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, to at least 5 protocol-identifiers, one for each encapsulation (e.g.
ip over LLC, etc.). ip over ether2, ip over LLC, etc.).
7. Base Layer Protocol Identifier Macros 4. Base Layer Protocol Identifier Macros
The following PROTOCOL IDENTIFIER macros can be used to construct The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParameters strings. protocolDirID and protocolDirParameters strings.
An identifier is encoded by constructing the base-identifier, then An identifier is encoded by constructing the base-identifier, then
adding one layer-identifier for each encapsulated protocol. adding one layer-identifier for each encapsulated protocol.
Refer to the RMON Protocol Identifier Macros document [RMONPROT_MAC] for Refer to the RMON Protocol Identifier Macros document [RFC2896] for a
a listing of the non-base layer PI macros published by the working 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 group. Note that other PI macro documents may exist, and it should be
possible for an implementor to populate the protocolDirTable without the possible for an implementor to populate the protocolDirTable without
use of the PI Macro document [RMONPROT_MAC]. the use of the PI Macro document [RFC2896].
7.1. Base Identifier Encoding 4.1. Base Identifier Encoding
The first layer encapsulation is called the base identifier and it The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the base layer (e.g. contains optional protocol-function information and the base layer
MAC layer) enumeration value used in this protocol identifier. (e.g. MAC layer) enumeration value used in this protocol identifier.
The base identifier is encoded as four octets as shown in figure 2. The base identifier is encoded as four octets as shown in figure 2.
Fig. 2 Fig. 2
base-identifier format base-identifier format
+---+---+---+---+ +---+---+---+---+
| | | | | | | | | |
| f |op1|op2| m | | f |op1|op2| m |
| | | | | | | | | |
+---+---+---+---+ octet +---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count | 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table 4.1. The first octet ('f') is the special function code, found in table
The next two octets ('op1' and 'op2') are operands for the indicated 4.1. The next two octets ('op1' and 'op2') are operands for the
function. If not used, an operand must be set to zero. The last octet, indicated function. If not used, an operand must be set to zero. The
'm', is the enumerated value for a particular base layer encapsulation, last octet, 'm', is the enumerated value for a particular base layer
found in table 4.2. All four octets are encoded in network-byte-order. encapsulation, found in table 4.2. All four octets are encoded in
network-byte-order.
7.1.1. Protocol Identifier Functions 4.1.1. Protocol Identifier Functions
The base layer identifier contains information about any special The base layer identifier contains information about any special
functions to perform during collections of this protocol, as well as the functions to perform during collections of this protocol, as well as
base layer encapsulation identifier. the base layer encapsulation identifier.
The first three octets of the identifier contain the function code and The first three octets of the identifier contain the function code
two optional operands. The fourth octet contains the particular base and two optional operands. The fourth octet contains the particular
layer encapsulation used in this protocol (fig. 2). base layer encapsulation used in this protocol (fig. 2).
Table 4.1 Assigned Protocol Identifier Functions Table 4.1 Assigned Protocol Identifier Functions
------------------------------------------------- -------------------------------------------------
Function ID Param1 Param2 Function ID Param1 Param2
---------------------------------------------------- ----------------------------------------------------
none 0 not used (0) not used (0) none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0) wildcard 1 not used (0) not used (0)
7.1.1.1. Function 0: None 4.1.1.1. Function 0: None
If the function ID field (1st octet) is equal to zero, the 'op1' and 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 'op2' fields (2nd and 3rd octets) must also be equal to zero. This
special value indicates that no functions are applied to the protocol special value indicates that no functions are applied to the protocol
identifier encoded in the remaining octets. The identifier represents a identifier encoded in the remaining octets. The identifier represents
normal protocol encapsulation. a normal protocol encapsulation.
7.1.1.2. Function 1: Protocol Wildcard Function 4.1.1.2. Function 1: Protocol Wildcard Function
The wildcard function (function-ID = 1), is used to aggregate counters, The wildcard function (function-ID = 1), is used to aggregate
by using a single protocol value to indicate potentially many base layer counters, by using a single protocol value to indicate potentially
encapsulations of a particular network layer protocol. A many base layer encapsulations of a particular network layer
protocolDirEntry of this type will match any base-layer encapsulation of protocol. A protocolDirEntry of this type will match any base-layer
the same network layer protocol. encapsulation of the same network layer protocol.
The 'op1' field (2nd octet) is not used and MUST be set to zero. The 'op1' field (2nd octet) is not used and MUST be set to zero.
The 'op2' field (3rd octet) is not used and MUST be set to zero. The 'op2' field (3rd octet) is not used and MUST be set to zero.
Each wildcard protocol identifier MUST be defined in terms of a 'base Each wildcard protocol identifier MUST be defined in terms of a 'base
encapsulation'. This SHOULD be as 'standard' as possible for encapsulation'. This SHOULD be as 'standard' as possible for
interoperability purposes. The lowest possible base layer value SHOULD interoperability purposes. The lowest possible base layer value
be chosen. So, if an encapsulation over 'ether2' is permitted, than SHOULD be chosen. So, if an encapsulation over 'ether2' is
this should be used as the base encapsulation. 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.
If not then an encapsulation over LLC should be used, if permitted. And It should be noted that an agent does not have to support the non-
so on for each of the defined base layers. It should be noted that an wildcard protocol identifier over the same base layer. For instance
agent does not have to support the non-wildcard protocol identifier over a token ring only device would not normally support IP over the
the same base layer. For instance a token ring only device would not ether2 base layer. Nevertheless it should use the ether2 base layer
normally support IP over the ether2 base layer. Nevertheless it should for defining the wildcard IP encapsulation. The agent MAY also
use the ether2 base layer for defining the wildcard IP encapsulation. support counting some or all of the individual encapsulations for the
The agent MAY also support counting some or all of the individual same protocols, in addition to wildcard counting. Note that the
encapsulations for the same protocols, in addition to wildcard counting. RMON-2 MIB [RFC2021] does not require that agents maintain counters
Note that the RMON-2 MIB [RFC2021] does not require that agents maintain for multiple encapsulations of the same protocol. It is an
counters for multiple encapsulations of the same protocol. It is an implementation-specific matter as to how an agent determines which
implementation-specific matter as to how an agent determines which protocol combinations to allow in the protocolDirTable at any given
protocol combinations to allow in the protocolDirTable at any given time.
time.
7.2. Base Layer Protocol Identifiers 4.2. Base Layer Protocol Identifiers
The base layer is mandatory, and defines the base encapsulation of the The base layer is mandatory, and defines the base encapsulation of
packet and any special functions for this identifier. the packet and any special functions for this identifier.
There are no suggested protocolDirParameters bits for the base layer. There are no suggested protocolDirParameters bits for the base layer.
The suggested value for the ProtocolDirDescr field for the base layer is The suggested value for the ProtocolDirDescr field for the base layer
given by the corresponding "Name" field in the table 4.2 below. However, is given by the corresponding "Name" field in the table 4.2 below.
implementations are only required to use the appropriate integer However, implementations are only required to use the appropriate
identifier values. integer identifier values.
For most base layer protocols, the protocolDirType field should contain For most base layer protocols, the protocolDirType field should
bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)' contain bits set for the 'hasChildren(0)' and '
attributes. However, the special 'ianaAssigned' base layer should have addressRecognitionCapable(1)' attributes. However, the special
no parameter or attribute bits set. 'ianaAssigned' base layer should have no parameter or attribute bits
set.
By design, only 255 different base layer encapsulations are supported. By design, only 255 different base layer encapsulations are
There are five base encapsulation values defined at this time. Very few supported. There are five base encapsulation values defined at this
new base encapsulations (e.g. for new media types) are expected to be time. Very few new base encapsulations (e.g. for new media types) are
added over time. expected to be added over time.
Table 4.2 Base Layer Encoding Values Table 4.2 Base Layer Encoding Values
-------------------------------------- --------------------------------------
Name ID Name ID
------------------ ------------------
ether2 1 ether2 1
llc 2 llc 2
snap 3 snap 3
vsnap 4 vsnap 4
ianaAssigned 5 ianaAssigned 5
-- Ether2 Encapsulation -- Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER ether2 PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"DIX Ethernet, also called Ethernet-II." "DIX Ethernet, also called Ethernet-II."
CHILDREN CHILDREN
"The Ethernet-II type field is used to select child protocols. "The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field. the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the Children of this protocol are encoded as [ 0.0.0.1 ], the
skipping to change at page 27, line 24 skipping to change at page 25, line 34
URL: URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 } ::= { 1 }
-- LLC Encapsulation -- LLC Encapsulation
llc PROTOCOL-IDENTIFIER llc PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"The Logical Link Control (LLC) 802.2 protocol." "The Logical Link Control (LLC) 802.2 protocol."
CHILDREN CHILDREN
"The LLC Source Service Access Point (SSAP) and Destination "The LLC Source Service Access Point (SSAP) and Destination
Service Access Point (DSAP) are used to select child protocols. Service Access Point (DSAP) are used to select child protocols.
Each of these is one octet long, although the least significant Each of these is one octet long, although the least significant
bit is a control bit and should be masked out in most situations. 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 Typically SSAP and DSAP (once masked) are the same for a given
protocol - each end implicitly knows whether it is the server or protocol - each end implicitly knows whether it is the server or
skipping to change at page 28, line 39 skipping to change at page 26, line 47
IEEE Registration Authority: IEEE Registration Authority:
IEEE Registration Authority IEEE Registration Authority
c/o Iris Ringel c/o Iris Ringel
IEEE Standards Dept IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331 445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331 Piscataway, NJ 08855-1331
Phone +1 908 562 3813 Phone +1 908 562 3813
Fax: +1 908 562 1571" Fax: +1 908 562 1571"
::= { 2 } ::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000) Encapsulation -- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
-- Encapsulation
snap PROTOCOL-IDENTIFIER snap PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC "The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC." restricted to LLC."
CHILDREN CHILDREN
"Children of 'snap' are identified by Ethernet-II type values; "Children of 'snap' are identified by Ethernet-II type values;
the SNAP Protocol Identifier field (PID) is used to select the the SNAP Protocol Identifier field (PID) is used to select the
appropriate child. The entire SNAP protocol header is consumed; appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after the child protocol is assumed to start at the next octet after
skipping to change at page 29, line 33 skipping to change at page 27, line 39
Ethernet-II type value in hexadecimal. The above example would Ethernet-II type value in hexadecimal. The above example would
be named: be named:
snap 0x0800" snap 0x0800"
ADDRESS-FORMAT ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC" "The address format for SNAP is the same as that for LLC"
DECODING DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA "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 and a single control octet will be present. There are then three
octets of Organizationally Unique Identifier (OUI) and two octets octets of Organizationally Unique Identifier (OUI) and two octets
of PID. For this encapsulation the OUI must be 0x000000 (see of PID. For this encapsulation the OUI must be 0x000000 (see
'vsnap' below for non-zero OUIs)." 'vsnap' below for non-zero OUIs)."
REFERENCE REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards "SNAP Identifier values are assigned by the IEEE Standards
Office. The address is: Office. The address is:
IEEE Registration Authority IEEE Registration Authority
c/o Iris Ringel c/o Iris Ringel
IEEE Standards Dept IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331 445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331 Piscataway, NJ 08855-1331
Phone +1 908 562 3813 Phone +1 908 562 3813
Fax: +1 908 562 1571" Fax: +1 908 562 1571"
::= { 3 } ::= { 3 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation -- Vendor SNAP over LLC (OUI != 000) Encapsulation
vsnap PROTOCOL-IDENTIFIER vsnap PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have "This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that have a a zero OUI. See 'snap' above for details of those that have a
zero OUI value." zero OUI value."
CHILDREN CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is "Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the 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 packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
skipping to change at page 30, line 42 skipping to change at page 28, line 44
'vsnap 0x080007'" 'vsnap 0x080007'"
ADDRESS-FORMAT ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc' "The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details." protocol identifier for more details."
DECODING DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP "Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed." Protocol Identifier is not parsed."
REFERENCE REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards "SNAP Identifier values are assigned by the IEEE Standards
Office. The address is: Office. The address is:
IEEE Registration Authority IEEE Registration Authority
c/o Iris Ringel c/o Iris Ringel
IEEE Standards Dept IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331 445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331 Piscataway, NJ 08855-1331
Phone +1 908 562 3813 Phone +1 908 562 3813
Fax: +1 908 562 1571" Fax: +1 908 562 1571"
::= { 4 } ::= { 4 }
-- IANA Assigned Protocols -- IANA Assigned Protocols
ianaAssigned PROTOCOL-IDENTIFIER ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { } ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"This branch contains protocols which do not conform easily to "This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer the hierarchical format utilized in the other link layer
skipping to change at page 31, line 26 skipping to change at page 29, line 26
identification difficult or impossible by examination of identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known' appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used). protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a different Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'limited extensibility' feature of the can be identified with the 'limited extensibility' feature of the
protocolDirTable, and do not need special IANA assignments. protocolDirTable, and do not need special IANA assignments.
A centrally located list of these enumerated protocols must be A centrally located list of these enumerated protocols must be
maintained by IANA to insure interoperability. (See section 5.3 maintained by IANA to insure interoperability. (See section 2.3
for details on the document update procedure.) Support for new for details on the document update procedure.) Support for new
link-layers will be added explicitly, and only protocols which link-layers will be added explicitly, and only protocols which
cannot possibly be represented in a better way will be considered cannot possibly be represented in a better way will be considered
as 'ianaAssigned' protocols. as 'ianaAssigned' protocols.
IANA protocols are identified by the base-layer-selector value [ 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 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer
value corresponding to the particular IANA protocol. value corresponding to the particular IANA protocol.
Do not create children of this protocol unless you are sure that Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers they cannot be handled by the more conventional link layers
skipping to change at page 32, line 11 skipping to change at page 30, line 11
where 'a', 'b' are the network byte order encodings of the high where 'a', 'b' are the network byte order encodings of the high
order byte and low order byte of the enumeration value for the order byte and low order byte of the enumeration value for the
particular IANA assigned protocol. particular IANA assigned protocol.
For example, a protocolDirID-fragment value of: For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1 0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3 defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the numeric value Children are named 'ianaAssigned' followed by the numeric value
of the particular IANA assigned protocol. The above example would of the particular IANA assigned protocol. The above example
be named: would be named:
'ianaAssigned 1' " 'ianaAssigned 1' "
DECODING DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not "The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded." decoded."
REFERENCE REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information "Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol." on each child of the IANA assigned protocol."
::= { 5 } ::= { 5 }
-- The following protocol-variant-identifier macro declarations are -- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a proprietary way, -- used to identify the RMONMIB IANA assigned protocols in a
-- by simple enumeration. -- proprietary way, by simple enumeration.
ipxOverRaw8023 PROTOCOL-IDENTIFIER ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx VARIANT-OF ipx
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { } ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over "This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field. 802.3, without a type field.
Refer to the macro for IPX for additional information about this Refer to the macro for IPX for additional information about this
protocol." protocol."
DECODING DECODING
"Whenever the 802.3 header indicates LLC a set of protocol "Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these 'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document." beyond the scope of this document."
::= { ::= {
ianaAssigned 1, -- [0.0.0.1] ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1] 802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
} }
7.3. Encapsulation Layers 4.3. Encapsulation Layers
Encapsulation layers are positioned between the base layer and the Encapsulation layers are positioned between the base layer and the
network layer. It is an implementation-specific matter whether a probe network layer. It is an implementation-specific matter whether a
exposes all such encapsulations in its RMON-2 Protocol Directory. probe exposes all such encapsulations in its RMON-2 Protocol
Directory.
7.3.1. IEEE 802.1Q 4.3.1. IEEE 802.1Q
RMON probes may encounter 'VLAN tagged' frames on monitored links. The RMON probes may encounter 'VLAN tagged' frames on monitored links.
IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and
[IEEE802.1D-1998], define an encapsulation layer inserted after the MAC [IEEE802.1D-1998], define an encapsulation layer inserted after the
layer and before the network layer. This section defines a PI macro MAC layer and before the network layer. This section defines a PI
which supports most (but not all) features of that encapsulation layer. macro which supports most (but not all) features of that
encapsulation layer.
Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring Most notably, the RMON PI macro '802-1Q' does not expose the Token
Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header. It Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN
is an implementation specific matter whether an RMON probe converts header. It is an implementation specific matter whether an RMON
LLC-Token Ring (LLC-TR) formatted frames to LLC-Native (LLC-N) format, probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native
for the purpose of RMON collection. (LLC-N) format, for the purpose of RMON collection.
In order to support the Ethernet and LLC-N formats in the most efficient In order to support the Ethernet and LLC-N formats in the most
manner, and still maintain alignment with the RMON-2 'collapsed' base efficient manner, and still maintain alignment with the RMON-2 '
layer approach (i.e., support for snap and vsnap), the children of collapsed' base layer approach (i.e., support for snap and vsnap),
802dot1Q are encoded a little differently than the children of other the children of 802dot1Q are encoded a little differently than the
base layer identifiers. children of other base layer identifiers.
802-1Q PROTOCOL-IDENTIFIER 802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { } PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0) hasChildren(0)
} }
DESCRIPTION DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header. "IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs. explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP- data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media. encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR- Also, no information held in the TCI field (including the TR-
skipping to change at page 33, line 47 skipping to change at page 32, line 4
"IEEE 802.1Q VLAN Encapsulation header. "IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs. explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP- data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media. encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR- Also, no information held in the TCI field (including the TR-
encap bit) is identified in protocolDirID strings utilizing this encap bit) is identified in protocolDirID strings utilizing this
PI macro." PI macro."
CHILDREN CHILDREN
"The first byte of the 4-byte child identifier is used to "The first byte of the 4-byte child identifier is used to
distinguish the particular base encoding that follows the 802.1Q distinguish the particular base encoding that follows the 802.1Q
header. The remaining three bytes are used exactly as defined by header. The remaining three bytes are used exactly as defined by
the indicated base layer encoding. the indicated base layer encoding.
In order to simplify the child encoding for the most common In order to simplify the child encoding for the most common
cases, the 'ether2' and 'snap' base layers are combined into a cases, the 'ether2' and 'snap' base layers are combined into a
single identifier, with a value of zero. The other baser layers single identifier, with a value of zero. The other base layers
are encoded with values taken from Table 4.2. are encoded with values taken from Table 4.2.
802-1Q Base ID Values 802-1Q Base ID Values
--------------------- ---------------------
Base Table 4.2 Base-ID Base Table 4.2 Base-ID
Layer Encoding Encoding Layer Encoding Encoding
------------------------------------- -------------------------------------
ether2 1 0 ether2 1 0
llc 2 2 llc 2 2
skipping to change at page 36, line 40 skipping to change at page 34, line 37
of the child identifier. The above example would be named: of the child identifier. The above example would be named:
'802-1Q 0x05000001'. " '802-1Q 0x05000001'. "
DECODING DECODING
"VLAN headers and tagged frame structure are defined in "VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]." [IEEE802.1Q]."
REFERENCE REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual "The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]." Bridged Local Area Networks [IEEE802.1Q]."
::= { ::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity -- snap 0x8100 ** excluded to reduce PD size & complexity
} }
8. Intellectual Property 5. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; neither does it represent that it has made any might or might not be available; neither does it represent that it
effort to identify any such rights. Information on the IETF's has made any effort to identify any such rights. Information on the
procedures with respect to rights in standards-track and standards- IETF's procedures with respect to rights in standards-track and
related documentation can be found in BCP-11. Copies of claims of standards-related documentation can be found in BCP-11. Copies of
rights made available for publication and any assurances of licenses to claims of rights made available for publication and any assurances of
be made available, or the result of an attempt made to obtain a general licenses to be made available, or the result of an attempt made to
license or permission for the use of such proprietary rights by obtain a general license or permission for the use of such
implementors or users of this specification can be obtained from the proprietary rights by implementors or users of this specification can
IETF Secretariat." be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary
which may cover technology that may be required to practice this rights which may cover technology that may be required to practice
standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
9. Acknowledgements 6. Acknowledgements
This document was produced by the IETF RMONMIB Working Group. This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their contributions The authors wish to thank the following people for their
to this document: contributions to this document:
Anil Singhal Anil Singhal
Frontier Software Development, Inc. Frontier Software Development, Inc.
Jeanne Haney Jeanne Haney
Bay Networks Bay Networks
Dan Hansen Dan Hansen
Network General Corp. Network General Corp.
Special thanks are in order to the following people for writing RMON PI Special thanks are in order to the following people for writing RMON
macro compilers, and improving the specification of the PI macro PI macro compilers, and improving the specification of the PI macro
language: language:
David Perkins David Perkins
DeskTalk Systems, Inc. DeskTalk Systems, Inc.
Skip Koppenhaver Skip Koppenhaver
Technically Elite, Inc. Technically Elite, Inc.
10. References 7. References
[AF-LANE-0021.000] [AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington,
LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over "LAN Emulation over ATM - Version 1.0", AF-
ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995. LANE-0021.000, ATM Forum, IBM, January 1995.
[AF-NM-TEST-0080.000] [AF-NM-TEST-0080.000] Network Management Sub-working Group, Test
Network Management Sub-working Group, Test Sub-working Group, A. Sub-working Group, A. Bierman, "Remote
Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- Monitoring MIB Extensions for ATM Networks",
NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997. AF- NM-TEST-0080.000, ATM Forum, Cisco Systems,
February 1997.
[IEEE802.1D-1998] [IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE
LAN MAN Standards Committee of the IEEE Computer Society, Computer Society, "Information technology --
"Information technology -- Telecommunications and information Telecommunications and information exchange
exchange between systems -- Local and metropolitan area networks -- between systems -- Local and metropolitan area
Common specification -- Part 3: Media Access Control (MAC) networks -- Common specification -- Part 3:
Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Media Access Control (MAC) Bridges", ISO/IEC
Electrical and Electronics Engineers, Inc., May 1998. Final DIS 15802-3 (IEEE P802.1D/D17) Institute
of Electrical and Electronics Engineers, Inc.,
May 1998.
[IEEE802.1Q] [IEEE802.1Q] LAN MAN Standards Committee of the IEEE
LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Computer Society, "IEEE Standards for Local and
Standards for Local and Metropolitan Area Networks: Virtual Bridged Metropolitan Area Networks: Virtual Bridged
Local Area Networks", Draft Standard P802.1Q/D11, Institute of Local Area Networks", Draft Standard
Electrical and Electronics Engineers, Inc., July 1998. P802.1Q/D11, Institute of Electrical and
Electronics Engineers, Inc., July 1998.
[RFC1155] [RFC1155] Rose, M. and K. McCloghrie, "Structure and
Rose, M., and K. McCloghrie, "Structure and Identification of Identification of Management Information for
Management Information for TCP/IP-based Internets", RFC 1155, TCP/IP-based Internets", STD 16, RFC 1155, May
Performance Systems International, Hughes LAN Systems, May 1990. 1990.
[RFC1157] [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J.
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Davin, "Simple Network Management Protocol",
Management Protocol", RFC 1157, SNMP Research, Performance Systems STD 15, RFC 1157, May 1990.
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[RFC1212] [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB
Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Definitions", STD 16, RFC 1212, March 1991.
Performance Systems International, Hughes LAN Systems, March 1991.
[RFC1215] [RFC1215] Rose, M., "A Convention for Defining Traps for
M. Rose, "A Convention for Defining Traps for use with the SNMP", use with the SNMP", RFC 1215, March 1991.
RFC 1215, Performance Systems International, March 1991.
[RFC1483] [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over
J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer ATM Adaptation Layer 5", RFC 1483, July 1993.
5", RFC 1483, Telecom Finland, July 1993.
[RFC1700] [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers",
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, STD 2, RFC 1700, October 1994.
USC/Information Sciences Institute, October 1994.
[RFC1901] [RFC1901] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMPv2", RFC 1901, January 1996.
SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
[RFC1902] [RFC1902] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management
Waldbusser, "Structure of Management Information for version 2 of Information for version 2 of the Simple Network
the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Management Protocol (SNMPv2)", RFC 1902,
Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., January 1996.
International Network Services, January 1996.
[RFC1903] [RFC1903] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2
Waldbusser, "Textual Conventions for version 2 of the Simple of the Simple Network Management Protocol
Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, (SNMPv2)", RFC 1903, January 1996.
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1904] [RFC1904] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version
Waldbusser, "Conformance Statements for version 2 of the Simple 2 of the Simple Network Management Protocol
Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, (SNMPv2)", RFC 1904, January 1996.
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1905] [RFC1905] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2
Waldbusser, "Protocol Operations for Version 2 of the Simple of the Simple Network Management Protocol
Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, (SNMPv2)", RFC 1905, January 1996.
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1906] [RFC1906] Case, J., McCloghrie, K., Rose, M. and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2
Waldbusser, "Transport Mappings for Version 2 of the Simple Network of the Simple Network Management Protocol
Management Protocol (SNMPv2)"", RFC 1906, SNMP Research, Inc., (SNMPv2)"", RFC 1906, January 1996.
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[RFC2021] [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, (RMON-2)", RFC 2021, January 1997.
International Network Services, January 1997.
[RFC2074] [RFC2074] Bierman, A. and R. Iddon, "Remote Network
Bierman, A., and R. Iddon, "Remote Network Monitoring MIB Protocol Monitoring MIB Protocol Identifiers", RFC 2074,
Identifiers", RFC 2074, Cisco Systems, 3Com Inc., January 1997. January 1997.
[RFC2119] [RFC2119] Bradner, S., "Key words for use in RFCs to
S. Bradner, "Key words for use in RFCs to Indicate Requirement Indicate Requirement Levels", BCP 14, RFC 2119,
Levels", RFC 2119, Harvard University, March 1997. March 1997.
[RFC2233] [RFC2233] McCloghrie, K. and F. Kastenholz, "The
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using Interfaces Group MIB Using SMIv2", RFC 2233,
SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997. November 1997.
[RFC2271] [RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Architecture for Describing SNMP Management
Describing SNMP Management Frameworks", RFC 2271, Cabletron Frameworks", RFC 2271, January 1998.
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
January 1998.
[RFC2272] [RFC2272] Case, J., Harrington D., Presuhn R. and B.
Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Wijnen, "Message Processing and Dispatching for
Processing and Dispatching for the Simple Network Management the Simple Network Management Protocol (SNMP)",
Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, RFC 2272, January 1998.
Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998.
[RFC2273] [RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC Applications", RFC 2273, January 1998.
2273, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, January 1998.
[RFC2274] [RFC2274] Blumenthal, U. and B. Wijnen, "User-based
Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for Security Model (USM) for version 3 of the
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC Simple Network Management Protocol (SNMPv3)",
2274, IBM T. J. Watson Research, January 1998. RFC 2274, January 1998.
[RFC2275] [RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie,
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access "View-based Access Control Model (VACM) for the
Control Model (VACM) for the Simple Network Management Protocol Simple Network Management Protocol (SNMP)", RFC
(SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 2275, January 1998.
Cisco Systems, Inc., January 1998.
[RMONPROT_MAC] [RFC2570] Case, J., Mundy, R., Partain, D. and B.
Bierman, A., Bucci, C., and R. Iddon, "Remote Network Monitoring Stewart, "Introduction to Version 3 of the
MIB Protocol Identifier Macros", draft-ietf-rmonmib-rmonprot-mac- Internet-standard Network Management
00.txt, Cisco Systems, 3Com, Inc., November 1998. Framework", RFC 2570, April 1999.
11. Security Considerations [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC 2571, April 1999.
This document discusses the syntax and semantics of textual descriptions [RFC2572] Case, J., Harrington D., Presuhn R. and B.
of networking protocols, not the definition of any networking behavior. Wijnen, "Message Processing and Dispatching for
As such, no security considerations are raised by this memo. the Simple Network Management Protocol (SNMP)",
RFC 2572, April 1999.
12. Authors' Addresses [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
Andy Bierman [RFC2574] Blumenthal, U. and B. Wijnen, "User-based
Cisco Systems, Inc. Security Model (USM) for version 3 of the
170 West Tasman Drive Simple Network Management Protocol (SNMPv3)",
San Jose, CA USA 95134 RFC 2574, April 1999.
Phone: +1 408-527-3711
Email: abierman@cisco.com
Chris Bucci [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie,
Cisco Systems, Inc. "View-based Access Control Model (VACM) for the
170 West Tasman Drive Simple Network Management Protocol (SNMP)", RFC
San Jose, CA USA 95134 2575, April 1999.
Phone: +1 408-527-5337
Email: cbucci@cisco.com
Robin Iddon [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
3Com, Inc. Case, J., Rose, M. and S. Waldbusser,
40/50 Blackfrias Street "Structure of Management Information Version 2
Edinburgh, UK (SMIv2)", STD 58, RFC 2578, April 1999.
Phone: +44 131.558.3888
Email: Robin_Iddon@3mail.3com.com
13. Full Copyright Statement [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April
1999.
Copyright (C) The Internet Society (1998). All Rights Reserved. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser,
"Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
This document and translations of it may be copied and furnished to [RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote
others, and derivative works that comment on or otherwise explain it or Network Monitoring MIB Protocol Identifier
assist in its implementation may be prepared, copied, published and Macros", RFC 2896, August 2000.
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 8. IANA Considerations
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS The protocols identified in this specification are almost entirely
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK defined in external documents. In some rare cases, an arbitrary
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT Protocol Identifier assignment must be made in order to support a
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT particular protocol in the RMON-2 protocolDirTable. Protocol
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR Identifier macros for such protocols will be defined under the '
FITNESS FOR A PARTICULAR PURPOSE." ianaAssigned' base layer (see sections 3. and 4.2).
At this time, only one protocol is defined under the ianaAssigned
base layer, called 'ipxOverRaw8023' (see section 4.2).
9. Security Considerations
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.
10. Authors' Addresses
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-3711
EMail: abierman@cisco.com
Chris Bucci
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-5337
EMail: cbucci@cisco.com
Robin Iddon
c/o 3Com Inc.
Blackfriars House
40/50 Blackfrias Street
Edinburgh, EH1 1NE, UK
Phone: +44 131.558.3888
EMail: None
Appendix A: Changes since RFC 2074
The differences between RFC 2074 and this document are:
- 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:
"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
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
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.
 End of changes. 301 change blocks. 
1065 lines changed or deleted 1064 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/