Request for Comments: 2895 C. Bucci
Obsoletes: 2074 Cisco Systems, Inc.
Category: Standards Track R. Iddon
3Com, Inc.
August 2000
Remote Network Monitoring MIB Protocol Identifier Reference
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo defines a notation describing protocol layers in a protocol
encapsulation, specifically for use in encoding INDEX values for the
protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring
Management Information Base) [RFC2021]. The definitions for the
standard protocol directory base layer identifiers are also included.
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.
This document obsoletes RFC2074.
Table of Contents
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
1. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC1155 [RFC1155], STD 16, RFC1212 [RFC1212] and RFC1215
[RFC1215]. The second version, called SMIv2, is described in STD
58, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [RFC1157]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [RFC1901]
and RFC1906 [RFC1906]. The third version of the message protocol
is called SNMPv3 and described in RFC1906 [RFC1906], RFC2572
[RFC2572] and RFC2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[RFC1905].
o A set of fundamental applications described in RFC2573 [RFC2573]
and the view-based access control mechanism described in RFC2575
[RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo does not specify a MIB module.
2. Overview
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs
to globally identify individual protocol encapsulations in the
protocolDirTable.
This guide contains algorithms and the authoritative set of base
layer protocol identifier macros, for use within INDEX values in the
protocolDirTable.
This is the second revision of this document, and is intended to
replace the first half of the first RMON-2 Protocol Identifiers
document. [RFC2074].
2.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 RFC2119 [RFC2119].
Several terms are used throughout this document, as well as in the
RMON-2 MIB [RFC2021], that should be introduced:
parent protocol:
Also called 'parent'; The encapsulating protocol identifier for
a specific protocol layer, e.g., IP is the parent protocol of
UDP. Note that base layers cannot have parent protocols. This
term may be used to refer to a specific encapsulating protocol,
or it may be used generically to refer to any encapsulating
protocol.
child protocol:
Also called 'child'; An encapsulated protocol identifier for a
specific protocol layer. e.g., UDP is a child protocol of IP.
This term may be used to refer to a specific encapsulated
protocol, or it may be used generically to refer to any
encapsulated protocol.
layer-identifier:
An octet string fragment representing a particular protocol
encapsulation layer or sub-layer. A fragment consists of
exactly four octets, encoded in network byte order. If present,
child layer-identifiers for a protocol MUST have unique values
among each other. (See section 3.3 for more details.)
protocol:
A particular protocol layer, as specified by encoding rules in
this document. Usually refers to a single layer in a given
encapsulation. Note that this term is sometimes used in the
RMON-2 MIB [RFC2021] to name a fully-specified protocol-
identifier string. In such a case, the protocol-identifier
string is named for its upper-most layer. A named protocol may
also refer to any encapsulation of that protocol.
protocol-identifier string:
An octet string representing a particular protocol
encapsulation, as specified by the encoding rules in this
document. This string is identified in the RMON-2 MIB [RFC2021]
as the protocolDirID object. A protocol-identifier string is
composed of one or more layer-identifiers read from left to
right. The left-most layer-identifier specifies a base layer
encapsulation. Each layer-identifier to the right specifies a
child layer protocol encapsulation.
protocol-identifier macro: Also called a PI macro; A macro-like
textual construct used to describe a particular networking
protocol. Only protocol attributes which are important for RMON
use are documented. Note that the term 'macro' is historical,
and PI macros are not real macros, nor are they ASN.1 macros.
The current set of published RMON PI macros can be found in the
RMON Protocol Identifier Macros document [RFC2896].
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.
protocol-variant-identifier macro:
Also called a PI-variant macro; A special kind of PI macro, used
to describe a particular protocol layer, which cannot be
identified with a deterministic, and (usually) hierarchical
structure, like most networking protocols.
Note that the PI-variant macro and the PI-macro are defined with
a single set of syntax rules (see section 3.2), except that
different sub-clauses are required for each type.
A protocol identified with a PI-variant macro is actually a
variant of a well known encapsulation that may be present in the
protocolDirTable. This is used to document the IANA assigned
protocols, which are needed to identify protocols which cannot
be practically identified by examination of 'appropriate network
traffic' (e.g. the packets which carry them). All other
protocols (which can be identified by examination of appropriate
network traffic) SHOULD be documented using the protocol-
identifier macro. (See section 3.2 for details.)
protocol-parameter:
A single octet, corresponding to a specific layer-identifier in
the protocol-identifier. This octet is a bit-mask indicating
special functions or capabilities that this agent is providing
for the corresponding protocol. (See section 3.2.6 for
details.)
protocol-parameters string:
An octet string, which contains one protocol-parameter for each
layer-identifier in the protocol-identifier. This string is
identified in the RMON-2 MIB [RFC2021] as the
protocolDirParameters object. (See the section 3.2.6 for
details.)
protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair
that have been converted to an INDEX value, according to the
encoding rules in section 7.7 of RFC1902 [RFC1902].
pseudo-protocol:
A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings.
protocol encapsulation tree:
Protocol encapsulations can be organized into an inverted tree.
The nodes of the root are the base encapsulations. The children
nodes, if any, of a node in the tree are the encapsulations of
child protocols.
2.2. Relationship to the Remote Network Monitoring MIB
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 intentionally separated from the RMON-2 MIB objects
[RFC2021] to allow updates to this document without any republication
of MIB objects.
This document does not discuss auto-discovery and auto-population of
the protocolDirTable. This functionality is not explicitly defined by
the RMON standard. An agent SHOULD populate the directory with the
'interesting' protocols on which the intended applications depend.
2.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.
These macros have been moved to a separate document called the RMON
Protocol Identifier Macros document [RFC2896]. This will allow the
normative text (this document) to advance on the standards track with
the RMON-2 MIB [RFC2021], while the collection of PI macros is
maintained in an Informational RFC.
The PI Macros document is intentionally separated from this document
to allow updates to the list of published PI macros without any
republication of MIB objects or encoding rules. Protocol Identifier
macros submitted from the RMON working group and community at large
(to the RMONMIB WG mailing list at 'rmonmib@ietf.org') will be
collected, screened by the RMONMIB working group, and (if approved)
added to a subsequent version of the PI Macros document.
Macros submissions will be collected in the IANA's MIB files under
the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in
the RMONMIB working group mailing list message archive file
www.ietf.org/mail-archive/working-
groups/rmonmib/current/maillist.htm.
2.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.
2.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.
2.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.
An NMS can determine some of the omitted encapsulation details by
examining the interface type (ifType) of the dataSource for a
particular RMON collection:
RFC1483 dataSource ifTypes:
- aal5(49)
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
These dataSources require implementation of the ifStackTable from the
Interfaces MIB [RFC2233]. It is possible that some implementations
will use dataSource values which indicate an ifType of 'atm(37)'
(because the ifStackTable is not supported), however this is strongly
discouraged by the RMONMIB WG.
2.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.
Probe implementations must use the AAL-5 frame size (not the AAL-5
payload size or encapsulated MAC frame size) as the 'frame size' for
the purpose of incrementing RMON-2 octet counters (e.g.,
'nlHostInOctets', 'alHostOutOctets').
The RMONMIB WG has not addressed issues relating to packet capture of
AAL-5 based traffic. Therefore, it is an implementation-specific
matter whether padding octets (i.e., RFC1483 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).
2.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.
3. 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 RFC1902 [RFC1902].
Then the index fragments are simply concatenated. (Refer to figures
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 a
particular node in the protocol encapsulation tree. The second OCTET
STRING, (protocolDirParameters) which contains a corresponding number
of 1-octet protocol-specific parameters, one for each 4-octet layer-
identifier in the first string.
A protocol layer is normally identified by a single 32-bit value.
Each layer-identifier is encoded in the ProtocolDirID OCTET STRING
INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent
each byte of the 32-bit value in network byte order. If a particular
protocol layer cannot be encoded into 32 bits, then it must be
defined as an 'ianaAssigned' protocol (see below for details on IANA
assigned protocols).
The following figures show the differences between the OBJECT
IDENTIFIER and OCTET STRING encoding of the protocol identifier
string.
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note
that the layer following the base layer usually identifies
a network layer protocol, but this is not always the case,
(most notably for children of the 'vsnap' base-layer).
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
When encoded in a protocolDirTable INDEX, each of the two
strings must be preceded by a length sub-component. In this
example, N equals '4', the first 'cnt' field would contain
the value '16', and the second 'cnt' field would contain
the value '4'.
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
Although this example indicates four encapsulated protocols, in
practice, any non-zero number of layer-identifiers may be present,
theoretically limited only by OBJECT IDENTIFIER length restrictions,
as specified in section 3.5 of RFC1902 [RFC1902].
3.1. ProtocolDirTable INDEX Format Examples
The following PI identifier fragments are examples of some fully
encoded protocolDirTable INDEX values for various encapsulations.
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023
ianaAssigned.ipxOverRaw8023.snmp =
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over UDP/IP over any link layer
ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2
ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether2
ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over vsnap
vsnap.apple-oui.atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
3.2. Protocol Identifier Macro Format
The following example is meant to introduce the protocol-identifier
macro. This macro-like construct is used to represent both protocols
and protocol-variants.
If the 'VariantOfPart' component of the macro is present, then the
macro represents a protocol-variant instead of a protocol. This
clause is currently used only for IANA assigned protocols, enumerated
under the 'ianaAssigned' base-layer. The VariantOfPart component
MUST be present for IANA assigned protocols.
3.2.1. Lexical Conventions
The PI language defines the following keywords:
ADDRESS-FORMAT
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
The PI language defines the following punctuation elements:
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
3.2.2. Notation for Syntax Descriptions
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:
* Literal values are specified in quotes, for example "REFERENCE"
* Non-terminal items are surrounded by less than (<) and greater
than (>) characters, for example <parmList>
* Terminal items are specified without surrounding quotes or less
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 be
repeated one or more times, for example <parm>...
* Square brackets are used to enclose optional items, for example
[ "," <parm> ]
* An equals character (=) is used to mean "defined as," for
example '<protoName> = pname'
3.2.3. Grammar for the PI Language
The following are "terminals" of the grammar and are identical to the
same lexical elements from the MIB module language, except for hstr
and pname:
<lc> = "a" | "b" | "c" | ... | "z"
<uc> = "A" | "B" | "C" | ... | "Z"
<letter> = <lc> | <uc>
<digit> = "0" | "1" | ... | "9"
<hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"
<lcname> = <lc> [ <lcrest> ]
<lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<pname> = ( <letter> | <digit> ) [ <pnrest> ]
<pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1
<hrest> = <hdigit> [ <hrest> ]
<lf> = linefeed char
<cr> = carriage return char
<eoln> = <cr><lf> | <lf>
<sp> = " "
<tab> = " "
<wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<string> = """ [ <strest> ] """
<strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
The following is the extended BNF notation for the grammar with
starting symbol <piFile>:
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name
<protoName> = pname
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
-- a parameter
<parm> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")" [<wspace>]
-- list of attributes
<attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
-- an attribute
<attr> = lcname [<wspace>] "(" [<wspace>]
<nonNegNum> [<wspace>] ")"
-- a non-negative number
<nonNegNum> = number | hstr
-- list of encapsulation values
<encapList> = <encapValue> [ [<wspace>] ","
[<wspace>] <encapValue> ]...
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- comment
<two dashes> <text> <end-of-line>
3.2.4. Mapping of the Protocol Name
The "protoName" value, called the "protocol name" shall be an ASCII
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 the
following:
"A" through "Z"
"a" through "z"
"0" through "9"
This value SHOULD be the name or acronym identifying the protocol.
Note that case is significant. The value selected for the protocol
name SHOULD match the "most well-known" name or acronym for the
indicated protocol. For example, the document indicated by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for
children of IP SHOULD be given names consistent with the protocol
names found in this authoritative document. Likewise, children of
UDP and TCP SHOULD be given names consistent with the port number
name assignments found in:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
When the "well-known name" contains characters not allowed in
protocol names, they MUST be changed to a dash character ("-") . In
the event that the first character must be changed, the protocol name
is prepended with the letter "p", so the former first letter may be
changed to a dash.
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The
following protocol names are legal:
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
Note that it is possible in actual implementation that different
encapsulations of the same protocol (which are represented by
different entries in the protocolDirTable) will be assigned the same
protocol name. The protocolDirID INDEX value defines a particular
protocol, not the protocol name string.
3.2.5. Mapping of the VARIANT-OF 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'.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference
protocol-identifier macro SHOULD NOT be duplicated in the protocol-
variant-identifier macro, if the 'variant' protocols' semantics are
identical for a given clause.
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a
protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e.
"PARAMETERS {}") MUST be present in a protocol-variant-identifier
macro, and the 'ParamList' and 'AttrList' found in the reference
protocol-identifier macro examined instead.
Note that if an 'ianaAssigned' protocol is defined that is not a
variant of any other documented protocol, then the protocol-
identifier macro SHOULD be used instead of the protocol-variant-
identifier version of the macro.
3.2.6. Mapping of the PARAMETERS Clause
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.
The PARAMETERS clause is a list of bit definitions which can be
directly encoded into the associated ProtocolDirParameters octet in
network byte order. Zero or more bit definitions may be present. Only
bits 0-7 are valid encoding values. This clause defines the entire
BIT set allowed for a given protocol. A conforming agent may choose
to implement a subset of zero or more of these PARAMETERS.
By convention, the following common bit definitions are used by
different protocols. These bit positions MUST NOT be used for other
parameters. They MUST be reserved if not used by a given protocol.
Bits are encoded in a single octet. Bit 0 is the high order (left-
most) bit in the octet, and bit 7 is the low order (right-most) bit
in the first octet. Reserved bits and unspecified bits in the octet
are set to zero.
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause MUST be present in all protocol-identifier
macro declarations, but may be equal to zero (empty).
3.2.6.1. Mapping of the 'countsFragments(0)' BIT
This bit indicates whether the probe is correctly attributing all
fragmented packets of the specified protocol, even if individual
frames carrying this protocol cannot be identified as such. Note
that the probe is not required to actually present any re-assembled
datagrams (for address-analysis, filtering, or any other purpose) to
the NMS.
This bit MUST only be set in a protocolDirParameters octet which
corresponds to a protocol that supports fragmentation and reassembly
in some form. Note that TCP packets are not considered 'fragmented-
streams' and so TCP is not eligible.
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.
3.2.6.2. Mapping of the 'tracksSessions(1)' BIT
The 'tracksSessions(1)' bit indicates whether frames which are part
of remapped sessions (e.g. TFTP download sessions) are correctly
counted by the probe. For such a protocol, the probe must usually
analyze all packets received on the indicated interface, and maintain
some state information, (e.g. the remapped UDP port number for TFTP).
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.
3.2.7. Mapping of the ATTRIBUTES Clause
The protocolDirType object provides an NMS with an indication of a
probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol.
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.
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
The ATTRIBUTES clause MUST be present in all protocol-identifier
macro declarations, but MAY be empty.
3.2.8. Mapping of the DESCRIPTION Clause
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,
and how that selection process is performed
- Details on how the value(s) are encoded in the protocol identifier
octet string
- Details on how child protocols are named with respect to their
parent protocol label(s)
The CHILDREN clause MUST be present in all protocol-identifier macro
declarations in which the 'hasChildren(0)' BIT is set in the
ATTRIBUTES clause.
3.2.10. Mapping of the ADDRESS-FORMAT Clause
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
format(s) used when encoding addresses.
This clause MUST be present in all protocol-identifier macro
declarations in which the 'addressRecognitionCapable(1)' BIT is set
in the ATTRIBUTES clause.
3.2.11. Mapping of the DECODING Clause
The DECODING clause provides a description of the decoding procedure
for the specified protocol. It contains useful decoding hints for the
implementor, but SHOULD NOT over-replicate information in documents
cited in the REFERENCE clause. It might contain a complete
description of any decoding information required.
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection
as well as information on determining the start of the child
protocol.
For 'addressRecognitionCapable' protocols this includes offset and
type information for the field(s) used to generate addresses.
The DECODING clause is optional, and MAY be omitted if the REFERENCE
clause contains pointers to decoding information for the specified
protocol.
3.2.12. Mapping of the REFERENCE Clause
If a publicly available reference document exists for this protocol
it SHOULD be listed here. Typically this will be a URL if possible;
if not then it will be the name and address of the controlling body.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the
amount of information which may currently be obtained from an
authoritative document, such as the Assigned Numbers document
[RFC1700]. Any duplication or paraphrasing of information should be
brief and consistent with the authoritative document.
The REFERENCE clause is optional, but SHOULD be implemented if an
authoritative reference exists for the protocol (especially for
standard protocols).
3.3. Evaluating an Index of the ProtocolDirTable
The following evaluation is done after a protocolDirTable INDEX value
has been converted into two OCTET STRINGs according to the INDEX
encoding rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the
protocolDirID, which length MUST be evenly divisible by four. The
protocolDirParameters length MUST be exactly one quarter of the
protocolDirID string length.
Protocol-identifier parsing starts with the base layer identifier,
which MUST be present, and continues for one or more upper layer
identifiers, until all OCTETs of the protocolDirID have been used.
Layers MUST NOT be skipped, so identifiers such as 'SNMP over IP' or
'TCP over ether2' can not exist.
The base-layer-identifier also contains a 'special function
identifier' which may apply to the rest of the protocol identifier.
Wild-carding at the base layer within a protocol encapsulation is the
only supported special function at this time. (See section 4.1.1.2
for details.)
After the protocol-identifier string (which is the value of
protocolDirID) has been parsed, each octet of the protocol-parameters
string is evaluated, and applied to the corresponding protocol layer.
A protocol-identifier label MAY map to more than one value. For
instance, 'ip' maps to 5 distinct values, one for each supported
encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'
in the RMON Protocol Identifier Macros document [RFC2896]).
It is important to note that these macros are conceptually expanded
at implementation time, not at run time.
If all the macros are expanded completely by substituting all
possible values of each label for each child protocol, a list of all
possible protocol-identifiers is produced. So 'ip' would result in 5
distinct protocol-identifiers. Likewise each child of 'ip' would map
to at least 5 protocol-identifiers, one for each encapsulation (e.g.
ip over ether2, ip over LLC, etc.).
4. Base Layer Protocol Identifier Macros
The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParameters strings.
An identifier is encoded by constructing the base-identifier, then
adding one layer-identifier for each encapsulated protocol.
Refer to the RMON Protocol Identifier Macros document [RFC2896] for a
listing of the non-base layer PI macros published by the working
group. Note that other PI macro documents may exist, and it should be
possible for an implementor to populate the protocolDirTable without
the use of the PI Macro document [RFC2896].
4.1. Base Identifier Encoding
The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the base layer
(e.g. MAC layer) enumeration value used in this protocol identifier.
The base identifier is encoded as four octets as shown in figure 2.
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table
4.1. The next two octets ('op1' and 'op2') are operands for the
indicated function. If not used, an operand must be set to zero. The
last octet, 'm', is the enumerated value for a particular base layer
encapsulation, found in table 4.2. All four octets are encoded in
network-byte-order.
4.1.1. Protocol Identifier Functions
The base layer identifier contains information about any special
functions to perform during collections of this protocol, as well as
the base layer encapsulation identifier.
The first three octets of the identifier contain the function code
and two optional operands. The fourth octet contains the particular
base layer encapsulation used in this protocol (fig. 2).
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
4.1.1.1. Function 0: None
If the function ID field (1st octet) is equal to zero, the 'op1' and
'op2' fields (2nd and 3rd octets) must also be equal to zero. This
special value indicates that no functions are applied to the protocol
identifier encoded in the remaining octets. The identifier represents
a normal protocol encapsulation.
4.1.1.2. Function 1: Protocol Wildcard Function
The wildcard function (function-ID = 1), is used to aggregate
counters, by using a single protocol value to indicate potentially
many base layer encapsulations of a particular network layer
protocol. A protocolDirEntry of this type will match any base-layer
encapsulation of the same network layer protocol.
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 'base
encapsulation'. This SHOULD be as 'standard' as possible for
interoperability purposes. The lowest possible base layer value
SHOULD be chosen. So, if an encapsulation over 'ether2' is
permitted, than this should be used as the base encapsulation. If not
then an encapsulation over LLC should be used, if permitted. And so
on for each of the defined base layers.