As per Relevance of the word reference, we have this rfc below:
Network Working Group A.
Request for Comments: 2895 C.
Obsoletes: 2074 Cisco Systems, Inc
Category: Standards Track R.
3Com, Inc
August 2000
Remote Network Monitoring MIB Protocol Identifier
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines a notation describing protocol layers in a
encapsulation, specifically for use in encoding INDEX values for
protocolDirTable, found in the RMON-2 MIB (Remote Network
Management Information Base) [RFC2021]. The definitions for
standard protocol directory base layer identifiers are also included
The first version of the RMON Protocol Identifiers Document [RFC2074]
has been split into a standards-track Reference portion (
document), and an Informational document. The RMON
Identifier Macros document [RFC2896] now contains the non-
portion of that specification
This document obsoletes RFC 2074.
Bierman, et al. Standards Track [Page 1]
RFC 2895 RMON PI Reference August 2000
Table of
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
Bierman, et al. Standards Track [Page 2]
RFC 2895 RMON PI Reference August 2000
1. The SNMP Network Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described in
16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
[RFC1215]. The second version, called SMIv2, is described in
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
2580 [RFC2580].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [RFC1157]. A second version of
SNMP message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
[RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [RFC1157]. A second set of
operations and associated PDU formats is described in RFC 1905
[RFC1905].
o A set of fundamental applications described in RFC 2573 [RFC2573]
and the view-based access control mechanism described in RFC 2575
[RFC2575].
A more detailed introduction to the current SNMP Management
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo does not specify a MIB module
2.
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET
to globally identify individual protocol encapsulations in
protocolDirTable
Bierman, et al. Standards Track [Page 3]
RFC 2895 RMON PI Reference August 2000
This guide contains algorithms and the authoritative set of
layer protocol identifier macros, for use within INDEX values in
protocolDirTable
This is the second revision of this document, and is intended
replace the first half of the first RMON-2 Protocol
document. [RFC2074].
2.1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
Several terms are used throughout this document, as well as in
RMON-2 MIB [RFC2021], that should be introduced
parent protocol
Also called 'parent'; The encapsulating protocol identifier
a specific protocol layer, e.g., IP is the parent protocol
UDP. Note that base layers cannot have parent protocols.
term may be used to refer to a specific encapsulating protocol
or it may be used generically to refer to any
protocol
child protocol
Also called 'child'; An encapsulated protocol identifier for
specific protocol layer. e.g., UDP is a child protocol of IP
This term may be used to refer to a specific
protocol, or it may be used generically to refer to
encapsulated protocol
layer-identifier
An octet string fragment representing a particular
encapsulation layer or sub-layer. A fragment consists
exactly four octets, encoded in network byte order. If present
child layer-identifiers for a protocol MUST have unique
among each other. (See section 3.3 for more details.)
protocol
A particular protocol layer, as specified by encoding rules
this document. Usually refers to a single layer in a
encapsulation. Note that this term is sometimes used in
RMON-2 MIB [RFC2021] to name a fully-specified protocol
identifier string. In such a case, the protocol-
string is named for its upper-most layer. A named protocol
also refer to any encapsulation of that protocol
Bierman, et al. Standards Track [Page 4]
RFC 2895 RMON PI Reference August 2000
protocol-identifier string
An octet string representing a particular
encapsulation, as specified by the encoding rules in
document. This string is identified in the RMON-2 MIB [RFC2021]
as the protocolDirID object. A protocol-identifier string
composed of one or more layer-identifiers read from left
right. The left-most layer-identifier specifies a base
encapsulation. Each layer-identifier to the right specifies
child layer protocol encapsulation
protocol-identifier macro: Also called a PI macro; A macro-
textual construct used to describe a particular
protocol. Only protocol attributes which are important for
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
RMON Protocol Identifier Macros document [RFC2896].
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
protocol
- Describes how the associated protocolDirType object is
for the protocol
- Provides reference(s) to authoritative documentation for
protocol
protocol-variant-identifier macro
Also called a PI-variant macro; A special kind of PI macro,
to describe a particular protocol layer, which cannot
identified with a deterministic, and (usually)
structure, like most networking protocols
Note that the PI-variant macro and the PI-macro are defined
a single set of syntax rules (see section 3.2), except
different sub-clauses are required for each type
A protocol identified with a PI-variant macro is actually
variant of a well known encapsulation that may be present in
protocolDirTable. This is used to document the IANA
protocols, which are needed to identify protocols which
be practically identified by examination of 'appropriate
traffic' (e.g. the packets which carry them). All
protocols (which can be identified by examination of
Bierman, et al. Standards Track [Page 5]
RFC 2895 RMON PI Reference August 2000
network traffic) SHOULD be documented using the protocol
identifier macro. (See section 3.2 for details.)
protocol-parameter
A single octet, corresponding to a specific layer-identifier
the protocol-identifier. This octet is a bit-mask
special functions or capabilities that this agent is
for the corresponding protocol. (See section 3.2.6
details.)
protocol-parameters string
An octet string, which contains one protocol-parameter for
layer-identifier in the protocol-identifier. This string
identified in the RMON-2 MIB [RFC2021] as
protocolDirParameters object. (See the section 3.2.6
details.)
protocolDirTable INDEX
A protocol-identifier and protocol-parameters octet string
that have been converted to an INDEX value, according to
encoding rules in section 7.7 of RFC 1902 [RFC1902].
pseudo-protocol
A convention or algorithm used only within this document for
purpose of encoding protocol-identifier strings
protocol encapsulation tree
Protocol encapsulations can be organized into an inverted tree
The nodes of the root are the base encapsulations. The
nodes, if any, of a node in the tree are the encapsulations
child protocols
2.2. Relationship to the Remote Network Monitoring
This document is intended to identify the encoding rules for
OCTET STRING objects protocolDirID and protocolDirParameters. RMON-2
tables, such as those in the new Protocol Distribution, Host,
Matrix groups, use a local INTEGER INDEX (protocolDirLocalIndex
rather than complete protocolDirTable INDEX strings, to
protocols for counting purposes. Only the protocolDirTable uses
protocolDirID and protocolDirParameters strings described in
document
This document is intentionally separated from the RMON-2 MIB
[RFC2021] to allow updates to this document without any
of MIB objects
Bierman, et al. Standards Track [Page 6]
RFC 2895 RMON PI Reference August 2000
This document does not discuss auto-discovery and auto-population
the protocolDirTable. This functionality is not explicitly defined
the RMON standard. An agent SHOULD populate the directory with
'interesting' protocols on which the intended applications depend
2.3. Relationship to the RMON Protocol Identifier Macros
The original RMON Protocol Identifiers document [RFC2074]
the protocol directory reference material, as well as many
of protocol identifier macros
These macros have been moved to a separate document called the
Protocol Identifier Macros document [RFC2896]. This will allow
normative text (this document) to advance on the standards track
the RMON-2 MIB [RFC2021], while the collection of PI macros
maintained in an Informational RFC
The PI Macros document is intentionally separated from this
to allow updates to the list of published PI macros without
republication of MIB objects or encoding rules. Protocol
macros submitted from the RMON working group and community at
(to the RMONMIB WG mailing list at 'rmonmib@ietf.org') will
collected, 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
the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and
the RMONMIB working group mailing list message archive
www.ietf.org/mail-archive/working
groups/rmonmib/current/maillist.htm
2.4. Relationship to the ATM-RMON
The ATM Forum has standardized "Remote Monitoring MIB Extensions
ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which
RMON-like stats, host, matrix, and matrixTopN capability for
address-based (ATM Adaption Layer 5, AAL-5) cell traffic
2.4.1. Port
It it possible to correlate ATM-RMON MIB data with packet-
RMON-2 [RFC2021] collections, but only if the ATM-
'portSelGrpTable' and 'portSelTable' are configured to provide
same level of port aggregation as used in the packet-
collection. This will require an ATM-RMON 'portSelectGroup'
contain a single port, in the case of traditional RMON dataSources
Bierman, et al. Standards Track [Page 7]
RFC 2895 RMON PI Reference August 2000
2.4.2. Encapsulation
The RMON PI document does not contain explicit PI macro support
"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
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
3.2 for details on identifying and decoding a particular base layer
An NMS can determine some of the omitted encapsulation details
examining the interface type (ifType) of the dataSource for
particular RMON collection
RFC 1483 dataSource ifTypes
- aal5(49)
LANE dataSource ifTypes
- aflane8023(59)
- aflane8025(60)
These dataSources require implementation of the ifStackTable from
Interfaces MIB [RFC2233]. It is possible that some
will use dataSource values which indicate an ifType of 'atm(37)'
(because the ifStackTable is not supported), however this is
discouraged by the RMONMIB WG
2.4.3. Counting ATM Traffic in RMON-2
The RMON-2 Application Layer (AL) and Network Layer (NL
(host/matrix/topN) tables require that octet counters be
by the size of the particular frame, not by the size of the
attributed to a given protocol
Probe implementations must use the AAL-5 frame size (not the AAL-5
payload size or encapsulated MAC frame size) as the 'frame size'
the purpose of incrementing RMON-2 octet counters (e.g.,
'nlHostInOctets', 'alHostOutOctets').
The RMONMIB WG has not addressed issues relating to packet capture
AAL-5 based traffic. Therefore, it is an implementation-
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
the captured frame is the first octet of the destination MAC
(DA).
Bierman, et al. Standards Track [Page 8]
RFC 2895 RMON PI Reference August 2000
2.5. Relationship to Other
The RMON Protocol Identifiers Reference document is intended for
with the protocolDirTable within the RMON MIB. It is not relevant
any other MIB, or intended for use with any other MIB
3. Protocol Identifier
The protocolDirTable is indexed by two OCTET STRINGs,
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
1a - 1d below for more detail.)
The first OCTET STRING (protocolDirID) is composed of one or more 4-
octet "layer-identifiers". The entire string uniquely identifies
particular node in the protocol encapsulation tree. The second
STRING, (protocolDirParameters) which contains a corresponding
of 1-octet protocol-specific parameters, one for each 4-octet layer
identifier in the first string
A protocol layer is normally identified by a single 32-bit value
Each layer-identifier is encoded in the ProtocolDirID OCTET
INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd'
each byte of the 32-bit value in network byte order. If a
protocol layer cannot be encoded into 32 bits, then it must
defined as an 'ianaAssigned' protocol (see below for details on
assigned protocols).
The following figures show the differences between the
IDENTIFIER and OCTET STRING encoding of the protocol
string
Fig. 1
protocolDirTable INDEX
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Bierman, et al. Standards Track [Page 9]
RFC 2895 RMON PI Reference August 2000
Fig. 1
protocolDirTable OCTET STRING
------------------------------------
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
+----------+
| |
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers
for the entire encapsulation of the named protocol.
that the layer following the base layer usually
a network layer protocol, but this is not always the case
(most notably for children of the 'vsnap' base-layer).
Fig. 1
protocolDirTable INDEX Format
-------------------------------------
protocolDirID
+---+--------+--------+--------+--------+---+---+---+---+---+
| 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 | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 |
When encoded in a protocolDirTable INDEX, each of the
strings must be preceded by a length sub-component. In
example, N equals '4', the first 'cnt' field would
the value '16', and the second 'cnt' field would
the value '4'.
Bierman, et al. Standards Track [Page 10]
RFC 2895 RMON PI Reference August 2000
Fig. 1
protocolDirTable OCTET STRING Format
--------------------------------------------
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+
| 4 | 4 | 4 | 4 |
+---+---+---+---+
|par|par|par|par
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+
| 1 | 1 | 1 | 1 |
Although this example indicates four encapsulated protocols,
practice, any non-zero number of layer-identifiers may be present
theoretically limited only by OBJECT IDENTIFIER length restrictions
as specified in section 3.5 of RFC 1902 [RFC1902].
3.1. ProtocolDirTable INDEX Format
The following PI identifier fragments are examples of some
encoded protocolDirTable INDEX values for various encapsulations
-- HTTP; fragments counted from IP and
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- SNMP over UDP/IP over
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023
ianaAssigned.ipxOverRaw8023.snmp =
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
Bierman, et al. Standards Track [Page 11]
RFC 2895 RMON PI Reference August 2000
-- IPX over
llc.ipx =
8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over UDP/IP over any link
ether2.ip.udp.
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether
ether2.
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether
ether2.
8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over
vsnap.apple-oui.
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
3.2. Protocol Identifier Macro
The following example is meant to introduce the protocol-
macro. This macro-like construct is used to represent both
and protocol-variants
If the 'VariantOfPart' component of the macro is present, then
macro represents a protocol-variant instead of a protocol.
clause is currently used only for IANA assigned protocols,
under the 'ianaAssigned' base-layer. The VariantOfPart
MUST be present for IANA assigned protocols
3.2.1. Lexical
The PI language defines the following keywords
ADDRESS-
PROTOCOL-
VARIANT-
Bierman, et al. Standards Track [Page 12]
RFC 2895 RMON PI Reference August 2000
The PI language defines the following punctuation elements
{ left curly
} right curly
( left
) right
,
::= two colons and an equal
-- two
3.2.2. Notation for Syntax
An extended form of the BNF notation is used to specify the syntax
the PI language. The rules for this notation are shown below
* Literal values are specified in quotes, for example "REFERENCE
* Non-terminal items are surrounded by less than (<) and
than (>) characters, for example
* Terminal items are specified without surrounding quotes or
than and greater than characters, for example 'lcname
* A vertical bar (|) is used to indicate a choice between items
for example 'number | hstr
* Ellipsis are used to indicate that the previous item may
repeated one or more times, for example ...
* Square brackets are used to enclose optional items, for
[ "," ]
* An equals character (=) is used to mean "defined as,"
example ' = pname
3.2.3. Grammar for the PI
The following are "terminals" of the grammar and are identical to
same lexical elements from the MIB module language, except for
and pname
= "a" | "b" | "c" | ... | "z
= "A" | "B" | "C" | ... | "Z
= |
= "0" | "1" | ... | "9"
= | "a" | "A" | "b" | "B" | ... | "f" | "F
Bierman, et al. Standards Track [Page 13]
RFC 2895 RMON PI Reference August 2000
= [ ]
= ( | | "-" ) [ ]
= ( | ) [ ]
= ( | | "-" | "_" | "*" ) [ ]
= [ ] -- to a max dec. value of 4g-1
= "0x" -- to a max dec. value of 4g-1
= [ ]
= linefeed
= carriage return
= |
= " "
= " "
= { | | } []
= """ [ ] """
= ( | | ) [ ]
The following is the extended BNF notation for the grammar
starting symbol :
-- a file containing one or more Protocol Identifier (PI
--
= ...
-- a PI
=
"PROTOCOL-IDENTIFIER
[ "VARIANT-OF" ]
"PARAMETERS" "{" [ ] "}"
"ATTRIBUTES" "{" [ ] "}"
"DESCRIPTION"
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" "}"
-- a protocol
=
-- a list of
= [ "," ]...
Bierman, et al. Standards Track [Page 14]
RFC 2895 RMON PI Reference August 2000
-- a
= lcname [] "(" []
[] ")" []
-- list of
= [ [] "," [] ]...
-- an
= lcname [] "(" []
[] ")"
-- a non-negative
= number |
-- list of encapsulation
= [ [] ","
[] ]...
-- an encapsulation
= |
-- base encapsulation
=
-- normal encapsulation
=
--
3.2.4. Mapping of the Protocol
The "protoName" value, called the "protocol name" shall be an
string consisting of one up to 64 characters from the following
"A" through "Z
"a" through "z
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
plus(+)
The first character of the protocol name is limited to one of
following
"A" through "Z
"a" through "z
Bierman, et al. Standards Track [Page 15]
RFC 2895 RMON PI Reference August 2000
"0" through "9"
This value SHOULD be the name or acronym identifying the protocol
Note that case is significant. The value selected for the
name SHOULD match the "most well-known" name or acronym for
indicated protocol. For example, the document indicated by the URL
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-
defines IP Protocol field values, so protocol-identifier macros
children of IP SHOULD be given names consistent with the
names found in this authoritative document. Likewise, children
UDP and TCP SHOULD be given names consistent with the port
name assignments found in
ftp://ftp.isi.edu/in-notes/iana/assignments/port-
When the "well-known name" contains characters not allowed
protocol names, they MUST be changed to a dash character ("-") .
the event that the first character must be changed, the protocol
is prepended with the letter "p", so the former first letter may
changed to a dash
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g.
following protocol names are legal
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_
Note that it is possible in actual implementation that
encapsulations of the same protocol (which are represented
different entries in the protocolDirTable) will be assigned the
protocol name. The protocolDirID INDEX value defines a
protocol, not the protocol name string
3.2.5. Mapping of the VARIANT-OF
This clause is present for IANA assigned protocols only.
identifies the protocol-identifier macro that most closely
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
is called a 'protocol-variant-identifier'.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the
protocol-identifier macro SHOULD NOT be duplicated in the protocol
variant-identifier macro, if the 'variant' protocols' semantics
identical for a given clause
Bierman, et al. Standards Track [Page 16]
RFC 2895 RMON PI Reference August 2000
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in
protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e
"PARAMETERS {}") MUST be present in a protocol-variant-
macro, and the 'ParamList' and 'AttrList' found in the
protocol-identifier macro examined instead
Note that if an 'ianaAssigned' protocol is defined that is not
variant of any other documented protocol, then the protocol
identifier macro SHOULD be used instead of the protocol-variant
identifier version of the macro
3.2.6. Mapping of the PARAMETERS
The protocolDirParameters object provides an NMS the ability to
on and off expensive probe resources. An agent may support a
parameter all the time, not at all, or subject to current
load
The PARAMETERS clause is a list of bit definitions which can
directly encoded into the associated ProtocolDirParameters octet
network byte order. Zero or more bit definitions may be present.
bits 0-7 are valid encoding values. This clause defines the
BIT set allowed for a given protocol. A conforming agent may
to implement a subset of zero or more of these PARAMETERS
By convention, the following common bit definitions are used
different protocols. These bit positions MUST NOT be used for
parameters. They MUST be reserved if not used by a given protocol
Bits are encoded in a single octet. Bit 0 is the high order (left
most) bit in the octet, and bit 7 is the low order (right-most)
in the first octet. Reserved bits and unspecified bits in the
are set to zero
Table 3.1 Reserved PARAMETERS
------------------------------------
Bit Name
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated
this protocol will be counted correctly
if this protocol fragments the upper
into multiple packets
1 tracksSessions correctly attributes all packets of a
which starts sessions on well known ports
sockets and then transfers them to
assigned ports or sockets thereafter (e.g. TFTP).
Bierman, et al. Standards Track [Page 17]
RFC 2895 RMON PI Reference August 2000
The PARAMETERS clause MUST be present in all protocol-
macro declarations, but may be equal to zero (empty).
3.2.6.1. Mapping of the 'countsFragments(0)'
This bit indicates whether the probe is correctly attributing
fragmented packets of the specified protocol, even if
frames carrying this protocol cannot be identified as such.
that the probe is not required to actually present any re-
datagrams (for address-analysis, filtering, or any other purpose)
the NMS
This bit MUST only be set in a protocolDirParameters octet
corresponds to a protocol that supports fragmentation and
in some form. Note that TCP packets are not considered 'fragmented
streams' and so TCP is not eligible
This bit MAY be set in more than one protocolDirParameters
within a protocolDirTable INDEX, in the event an agent can
fragments at more than one protocol layer
3.2.6.2. Mapping of the 'tracksSessions(1)'
The 'tracksSessions(1)' bit indicates whether frames which are
of remapped sessions (e.g. TFTP download sessions) are
counted by the probe. For such a protocol, the probe must
analyze all packets received on the indicated interface, and
some state information, (e.g. the remapped UDP port number for TFTP).
The semantics of the 'tracksSessions' parameter are independent
the other protocolDirParameters definitions, so this parameter MAY
combined with any other legal parameter configurations
3.2.7. Mapping of the ATTRIBUTES
The protocolDirType object provides an NMS with an indication of
probe's capabilities for decoding a given protocol, or the
attributes of the particular protocol
The ATTRIBUTES clause is a list of bit definitions which are
into the associated instance of ProtocolDirType. The BIT
are specified in the SYNTAX clause of the protocolDirType MIB object
Bierman, et al. Standards Track [Page 18]
RFC 2895 RMON PI Reference August 2000
Table 3.2 Reserved ATTRIBUTES
------------------------------------
Bit Name
---------------------------------------------------------------------
0 hasChildren indicates that there may be children
this protocol defined in the
(by either the agent or the manager).
1
indicates that this protocol can be
to generate host and matrix table entries
The ATTRIBUTES clause MUST be present in all protocol-
macro declarations, but MAY be empty
3.2.8. Mapping of the DESCRIPTION
The DESCRIPTION clause provides a textual description of the
identified by this macro. Notice that it SHOULD NOT contain
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING
REFERENCE clauses
The DESCRIPTION clause MUST be present in all protocol-
macro declarations
3.2.9. Mapping of the CHILDREN
The CHILDREN clause provides a description of child protocols
protocols which support them. It has three sub-sections
- Details on the field(s)/value(s) used to select the child protocol
and how that selection process is
- Details on how the value(s) are encoded in the protocol
octet
- Details on how child protocols are named with respect to
parent protocol label(s
The CHILDREN clause MUST be present in all protocol-identifier
declarations in which the 'hasChildren(0)' BIT is set in
ATTRIBUTES clause
Bierman, et al. Standards Track [Page 19]
RFC 2895 RMON PI Reference August 2000
3.2.10. Mapping of the ADDRESS-FORMAT
The ADDRESS-FORMAT clause provides a description of the OCTET-
format(s) used when encoding addresses
This clause MUST be present in all protocol-identifier
declarations in which the 'addressRecognitionCapable(1)' BIT is
in the ATTRIBUTES clause
3.2.11. Mapping of the DECODING
The DECODING clause provides a description of the decoding
for the specified protocol. It contains useful decoding hints for
implementor, but SHOULD NOT over-replicate information in
cited in the REFERENCE clause. It might contain a
description of any decoding information required
For 'extensible' protocols ('hasChildren(0)' BIT set) this
offset and type information for the field(s) used for child
as well as information on determining the start of the
protocol
For 'addressRecognitionCapable' protocols this includes offset
type information for the field(s) used to generate addresses
The DECODING clause is optional, and MAY be omitted if the
clause contains pointers to decoding information for the
protocol
3.2.12. Mapping of the REFERENCE
If a publicly available reference document exists for this
it SHOULD be listed here. Typically this will be a URL if possible
if not then it will be the name and address of the controlling body
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit
amount of information which may currently be obtained from
authoritative document, such as the Assigned Numbers
[RFC1700]. Any duplication or paraphrasing of information should
brief and consistent with the authoritative document
The REFERENCE clause is optional, but SHOULD be implemented if
authoritative reference exists for the protocol (especially
standard protocols).
Bierman, et al. Standards Track [Page 20]
RFC 2895 RMON PI Reference August 2000
3.3. Evaluating an Index of the
The following evaluation is done after a protocolDirTable INDEX
has been converted into two OCTET STRINGs according to the
encoding rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with
protocolDirID, which length MUST be evenly divisible by four.
protocolDirParameters length MUST be exactly one quarter of
protocolDirID string length
Protocol-identifier parsing starts with the base layer identifier
which MUST be present, and continues for one or more upper
identifiers, until all OCTETs of the protocolDirID have been used
Layers MUST NOT be skipped, so identifiers such as 'SNMP over IP'
'TCP over ether2' can not exist
The base-layer-identifier also contains a 'special
identifier' which may apply to the rest of the protocol identifier
Wild-carding at the base layer within a protocol encapsulation is
only supported special function at this time. (See section 4.1.1.2
for details.)
After the protocol-identifier string (which is the value
protocolDirID) has been parsed, each octet of the protocol-
string is evaluated, and applied to the corresponding protocol layer
A protocol-identifier label MAY map to more than one value.
instance, 'ip' maps to 5 distinct values, one for each
encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers
in the RMON Protocol Identifier Macros document [RFC2896]).
It is important to note that these macros are conceptually
at implementation time, not at run time
If all the macros are expanded completely by substituting
possible values of each label for each child protocol, a list of
possible protocol-identifiers is produced. So 'ip' would result in 5
distinct protocol-identifiers. Likewise each child of 'ip' would
to at least 5 protocol-identifiers, one for each encapsulation (e.g
ip over ether2, ip over LLC, etc.).
Bierman, et al. Standards Track [Page 21]
RFC 2895 RMON PI Reference August 2000
4. Base Layer Protocol Identifier
The following PROTOCOL IDENTIFIER macros can be used to
protocolDirID and protocolDirParameters strings
An identifier is encoded by constructing the base-identifier,
adding one layer-identifier for each encapsulated protocol
Refer to the RMON Protocol Identifier Macros document [RFC2896] for
listing of the non-base layer PI macros published by the
group. Note that other PI macro documents may exist, and it should
possible for an implementor to populate the protocolDirTable
the use of the PI Macro document [RFC2896].
4.1. Base Identifier
The first layer encapsulation is called the base identifier and
contains optional protocol-function information and the base
(e.g. MAC layer) enumeration value used in this protocol identifier
The base identifier is encoded as four octets as shown in figure 2.
Fig. 2
base-identifier
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+
| 1 | 1 | 1 | 1 |
The first octet ('f') is the special function code, found in
4.1. The next two octets ('op1' and 'op2') are operands for
indicated function. If not used, an operand must be set to zero.
last octet, 'm', is the enumerated value for a particular base
encapsulation, found in table 4.2. All four octets are encoded
network-byte-order
4.1.1. Protocol Identifier
The base layer identifier contains information about any
functions to perform during collections of this protocol, as well
the base layer encapsulation identifier
The first three octets of the identifier contain the function
and two optional operands. The fourth octet contains the
base layer encapsulation used in this protocol (fig. 2).
Bierman, et al. Standards Track [Page 22]
RFC 2895 RMON PI Reference August 2000
Table 4.1 Assigned Protocol Identifier
-------------------------------------------------
Function ID Param1 Param
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
4.1.1.1. Function 0:
If the function ID field (1st octet) is equal to zero, the 'op1'
'op2' fields (2nd and 3rd octets) must also be equal to zero.
special value indicates that no functions are applied to the
identifier encoded in the remaining octets. The identifier
a normal protocol encapsulation
4.1.1.2. Function 1: Protocol Wildcard
The wildcard function (function-ID = 1), is used to
counters, by using a single protocol value to indicate
many base layer encapsulations of a particular network
protocol. A protocolDirEntry of this type will match any base-
encapsulation of the same network layer protocol
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
Each wildcard protocol identifier MUST be defined in terms of a '
encapsulation'. This SHOULD be as 'standard' as possible
interoperability purposes. The lowest possible base layer
SHOULD be chosen. So, if an encapsulation over 'ether2'
permitted, than this should be used as the base encapsulation. If
then an encapsulation over LLC should be used, if permitted. And
on for each of the defined base layers
It should be noted that an agent does not have to support the non
wildcard protocol identifier over the same base layer. For
a token ring only device would not normally support IP over
ether2 base layer. Nevertheless it should use the ether2 base
for defining the wildcard IP encapsulation. The agent MAY
support counting some or all of the individual encapsulations for
same protocols, in addition to wildcard counting. Note that
RMON-2 MIB [RFC2021] does not require that agents maintain
for multiple encapsulations of the same protocol. It is
implementation-specific matter as to how an agent determines
protocol combinations to allow in the protocolDirTable at any
time
Bierman, et al. Standards Track [Page 23]
RFC 2895 RMON PI Reference August 2000
4.2. Base Layer Protocol
The base layer is mandatory, and defines the base encapsulation
the packet and any special functions for this identifier
There are no suggested protocolDirParameters bits for the base layer
The suggested value for the ProtocolDirDescr field for the base
is given by the corresponding "Name" field in the table 4.2 below
However, implementations are only required to use the
integer identifier values
For most base layer protocols, the protocolDirType field
contain bits set for the 'hasChildren(0)' and '
addressRecognitionCapable(1)' attributes. However, the
'ianaAssigned' base layer should have no parameter or attribute
set
By design, only 255 different base layer encapsulations
supported. There are five base encapsulation values defined at
time. Very few new base encapsulations (e.g. for new media types)
expected to be added over time
Table 4.2 Base Layer Encoding
--------------------------------------
Name
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2
ether2 PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"DIX Ethernet, also called Ethernet-II."
"The Ethernet-II type field is used to select child protocols
This is a 16-bit field. Child protocols are deemed to start
the first octet after this type field
Bierman, et al. Standards Track [Page 24]
RFC 2895 RMON PI Reference August 2000
Children of this protocol are encoded as [ 0.0.0.1 ],
protocol identifier for 'ether2' followed by [ 0.0.a.b ]
'a' and 'b' are the network byte order encodings of the
order byte and low order byte of the Ethernet-II type value
For example, a protocolDirID-fragment value of
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
Children of ether2 are named as 'ether2' followed by the
field value in hexadecimal. The above example would be
as
ether2 0x0800"
ADDRESS-
"Ethernet addresses are 6 octets in network order."
"Only type values greater than 1500 decimal indicate Ethernet-
frames; lower values indicate 802.3 encapsulation (see below)."
"The authoritative list of Ether Type values is identified by
URL
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
::= { 1 }
-- LLC
llc PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"The Logical Link Control (LLC) 802.2 protocol."
"The LLC Source Service Access Point (SSAP) and
Service Access Point (DSAP) are used to select child protocols
Each of these is one octet long, although the least
bit is a control bit and should be masked out in most situations
Typically SSAP and DSAP (once masked) are the same for a
protocol - each end implicitly knows whether it is the server
client in a client/server protocol. This is only a convention
however, and it is possible for them to be different. The
is matched against child protocols first. If none is found
the DSAP is matched instead. The child protocol is deemed
start at the first octet after the LLC control field(s).
Bierman, et al. Standards Track [Page 25]
RFC 2895 RMON PI Reference August 2000
Children of 'llc' are encoded as [ 0.0.0.2 ], the
identifier component for LLC followed by [ 0.0.0.a ] where 'a'
the SAP value which maps to the child protocol. For example,
protocolDirID-fragment value of
0.0.0.2.0.0.0.240
defines NetBios over LLC
Children are named as 'llc' followed by the SAP value
hexadecimal. So the above example would have been named
llc 0xf0"
ADDRESS-
"The address consists of 6 octets of MAC address in
order. Source routing bits should be stripped out of the
if present."
"Notice that LLC has a variable length protocol header; there
always three octets (DSAP, SSAP, control). Depending on
value of the control bits in the DSAP, SSAP and control
there may be an additional octet of control information
LLC can be present on several different media. For 802.3
802.5 its presence is mandated (but see ether2 and raw 802.3
encapsulations). For 802.5 there is no other link
protocol
Notice also that the raw802.3 link layer protocol may
precedence over this one in a protocol specific manner such
it may not be possible to utilize all LSAP values if raw802.3
also present."
"The authoritative list of LLC LSAP values is controlled by
IEEE Registration Authority
IEEE Registration
c/o Iris
IEEE Standards
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
--
snap PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
Bierman, et al. Standards Track [Page 26]
RFC 2895 RMON PI Reference August 2000
hasChildren(0),
addressRecognitionCapable(1)
}
"The Sub-Network Access Protocol (SNAP) is layered on top of
protocol, allowing Ethernet-II protocols to be run over a
restricted to LLC."
"Children of 'snap' are identified by Ethernet-II type values
the SNAP Protocol Identifier field (PID) is used to select
appropriate child. The entire SNAP protocol header is consumed
the child protocol is assumed to start at the next octet
the PID
Children of 'snap' are encoded as [ 0.0.0.3 ], the
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b
are the high order byte and low order byte of the Ethernet-
type value
For example, a protocolDirID-fragment value of
0.0.0.3.0.0.8.0
defines the IP/SNAP protocol
Children of this protocol are named 'snap' followed by
Ethernet-II type value in hexadecimal. The above example
be named
snap 0x0800"
ADDRESS-
"The address format for SNAP is the same as that for LLC
"SNAP is only present over LLC. Both SSAP and DSAP will be 0
and a single control octet will be present. There are then
octets of Organizationally Unique Identifier (OUI) and two
of PID. For this encapsulation the OUI must be 0x000000 (
'vsnap' below for non-zero OUIs)."
"SNAP Identifier values are assigned by the IEEE
Office. The address is
IEEE Registration
c/o Iris
IEEE Standards
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
Bierman, et al. Standards Track [Page 27]
RFC 2895 RMON PI Reference August 2000
-- Vendor SNAP over LLC (OUI != 000)
vsnap PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"This pseudo-protocol handles all SNAP packets which do not
a zero OUI. See 'snap' above for details of those that have
zero OUI value."
"Children of 'vsnap' are selected by the 3 octet OUI; the PID
not parsed; child protocols are deemed to start with the
octet of the SNAP PID field, and continue to the end of
packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ],
protocol identifier for 'vsnap', followed by [ 0.a.b.c ]
'a', 'b' and 'c' are the 3 octets of the OUI field in
byte order
For example, a protocolDirID-fragment value of
0.0.0.4.0.8.0.7 defines the Apple-specific set of
over vsnap
Children are named as 'vsnap ', where the '' field
represented as 3 octets in hexadecimal notation
So the above example would be named
'vsnap 0x080007'"
ADDRESS-
"The LLC address format is inherited by 'vsnap'. See the 'llc
protocol identifier for more details."
"Same as for 'snap' except the OUI is non-zero and the
Protocol Identifier is not parsed."
"SNAP Identifier values are assigned by the IEEE
Office. The address is
IEEE Registration
c/o Iris
IEEE Standards
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
Bierman, et al. Standards Track [Page 28]
RFC 2895 RMON PI Reference August 2000
-- IANA Assigned
ianaAssigned PROTOCOL-
PARAMETERS { }
ATTRIBUTES { }
"This branch contains protocols which do not conform easily
the hierarchical format utilized in the other link
branches. Usually, such a protocol 'almost' conforms to
particular 'well-known' identifier format, but
criteria are used (e.g. configuration-based), making
identification difficult or impossible by examination
appropriate network traffic (preventing the any 'well-known
protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a
port number by one or more venders (e.g. SNMP). These
can be identified with the 'limited extensibility' feature of
protocolDirTable, and do not need special IANA assignments
A centrally located list of these enumerated protocols must
maintained by IANA to insure interoperability. (See section 2.3
for details on the document update procedure.) Support for
link-layers will be added explicitly, and only protocols
cannot possibly be represented in a better way will be
as 'ianaAssigned' protocols
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
value corresponding to the particular IANA protocol
Do not create children of this protocol unless you are sure
they cannot be handled by the more conventional link
above."
"Children of this protocol are identified by implementation
specific means, described (as best as possible) in the 'DECODING
clause within the protocol-variant-identifier macro for
enumerated protocol
Children of this protocol are encoded as [ 0.0.0.5 ],
protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ]
where 'a', 'b' are the network byte order encodings of the
order byte and low order byte of the enumeration value for
particular IANA assigned protocol
Bierman, et al. Standards Track [Page 29]
RFC 2895 RMON PI Reference August 2000
For example, a protocolDirID-fragment value of
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the numeric
of the particular IANA assigned protocol. The above
would be named
'ianaAssigned 1' "
"The 'ianaAssigned' base layer is a pseudo-protocol and is
decoded."
"Refer to individual PROTOCOL-IDENTIFIER macros for
on each child of the IANA assigned protocol."
::= { 5 }
-- The following protocol-variant-identifier macro declarations
-- used to identify the RMONMIB IANA assigned protocols in
-- proprietary way, by simple enumeration
ipxOverRaw8023 PROTOCOL-
VARIANT-OF
PARAMETERS { }
ATTRIBUTES { }
"This pseudo-protocol describes an encapsulation of IPX
802.3, without a type field
Refer to the macro for IPX for additional information about
protocol."
"Whenever the 802.3 header indicates LLC a set of
specific tests needs to be applied to determine whether this is
'raw8023' packet or a true 802.2 packet. The nature of
tests depends on the active child protocols for 'raw8023' and
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
Bierman, et al. Standards Track [Page 30]
RFC 2895 RMON PI Reference August 2000
4.3. Encapsulation
Encapsulation layers are positioned between the base layer and
network layer. It is an implementation-specific matter whether
probe exposes all such encapsulations in its RMON-2
Directory
4.3.1. IEEE 802.1
RMON probes may encounter 'VLAN tagged' frames on monitored links
The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q]
[IEEE802.1D-1998], define an encapsulation layer inserted after
MAC layer and before the network layer. This section defines a
macro which supports most (but not all) features of
encapsulation layer
Most notably, the RMON PI macro '802-1Q' does not expose the
Ring Encapsulation (TR-encaps) bit in the TCI portion of the
header. It is an implementation specific matter whether an
probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-
(LLC-N) format, for the purpose of RMON collection
In order to support the 