Remote Network Monitoring MIB Protocol Identifier Reference
obsoletes
- rfc-2074 — Remote Network Monitoring MIB Protocol Identifiers
updated by
- rfc-3395 — Remote Network Monitoring MIB Protocol Identifier Reference Extensions
Extracted elements (30)
PI macros are conceptually expanded at implementation time, not at run time. If all macros are expanded by substituting all possible values, a complete list of protocol-identifiers is produced — this is the intended evaluation model.
RFC 2074 was split into this normative reference document (standards-track) and a separate informational PI Macros document [RFC2896] to allow the encoding rules and MIB to advance on the standards track independently of the growing collection of protocol identifier macros.
The 802-1Q PI macro combines ether2 and snap into a single Base-ID value of zero to support the collapsed base layer approach (snap and vsnap) in the most efficient manner while maintaining alignment with RMON-2 design; this is noted as a deliberate simplification.
The ianaAssigned pseudo-protocol exists for protocols that 'almost' conform to a well-known identifier format but require additional criteria (e.g., configuration-based) for identification, making them impossible to identify by packet examination alone. A centrally maintained IANA list is required for interoperability.
ATM encapsulations (RFC 1483, LANE) are not represented by explicit PI macros; a probe must map ATM traffic to one of the existing base layers (llc, snap, or vsnap) regardless of how the raw data was obtained (VC-muxing vs. LLC-muxing, routed vs. bridged).
For RMON-2 AL/NL table octet counters, probe implementations must use the AAL-5 frame size (not the AAL-5 payload or encapsulated MAC frame size) as the frame size when incrementing RMON-2 octet counters.
A wildcard protocol identifier MUST be defined in terms of a base encapsulation chosen as the lowest possible base layer value (e.g., ether2 preferred over llc) for interoperability purposes.
Child layer-identifiers for a protocol MUST have unique values among each other within the protocol-identifier string.
For the wildcard function (function-ID=1), the 'op1' field (2nd octet) and 'op2' field (3rd octet) are not used and MUST be set to zero.
Protocol layers MUST NOT be skipped when constructing a protocol-identifier string; identifiers such as 'SNMP over IP' (omitting the transport layer) cannot exist.
Protocol names SHOULD match the most well-known name or acronym for the indicated protocol. When a well-known name contains characters not allowed in protocol names, they MUST be changed to a dash character ('-').
Protocols that can be identified by examination of appropriate network traffic SHOULD be documented using the protocol-identifier macro rather than the protocol-variant-identifier macro.
The ADDRESS-FORMAT clause MUST be present in all PI macro declarations in which the 'addressRecognitionCapable(1)' bit is set in the ATTRIBUTES clause.
The CHILDREN clause MUST be present in all PI macro declarations in which the 'hasChildren(0)' bit is set in the ATTRIBUTES clause.
The countsFragments(0) bit MUST only be set in a protocolDirParameters octet corresponding to a protocol that supports fragmentation and reassembly; TCP is explicitly excluded as it is not considered a fragmented-stream protocol.
The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, though it may be empty. Similarly, the ATTRIBUTES and DESCRIPTION clauses MUST be present in all PI macro declarations.
The protocolDirID length MUST be evenly divisible by four, and the protocolDirParameters length MUST be exactly one quarter of the protocolDirID string length.
The VARIANT-OF clause MUST be present for IANA assigned protocols. Additionally, an empty PARAMETERS and ATTRIBUTES clause (e.g., 'PARAMETERS {}') MUST be present in a protocol-variant-identifier macro.
Five base layer encapsulation values are defined in Table 4.2: ether2(1), llc(2), snap(3), vsnap(4), and ianaAssigned(5). These are the only supported base layer identifiers; very few new ones are expected to be added.
The 802-1Q PI macro represents the IEEE 802.1Q VLAN encapsulation header inserted between the MAC layer and the network layer. It does not expose the TCI field or the TR-encaps bit; TPID encoding differences (Ethernet vs. SNAP) are inferred from the ifType of the dataSource.
The ATTRIBUTES clause defines bits encoded into protocolDirType: hasChildren(0) indicates child protocols may be defined in the protocolDirTable, and addressRecognitionCapable(1) indicates the protocol can generate host and matrix table entries.
The ianaAssigned pseudo-protocol (base layer value 5) handles protocols that cannot be identified deterministically from network traffic alone. IANA maintains a central enumeration to ensure interoperability; children are encoded as [0.0.0.5] followed by [0.0.a.b] for the protocol enumeration value.
The PARAMETERS clause defines per-protocol bit definitions encoded into the protocolDirParameters octet. Two reserved bits are defined: countsFragments(0) indicating correct fragment attribution, and tracksSessions(1) indicating correct tracking of remapped session ports (e.g., TFTP).
Two protocol identifier functions are defined in Table 4.1: none(0), indicating a normal encapsulation with no special processing, and wildcard(1), which aggregates counters across all base layer encapsulations of a given network layer protocol.
IANA maintains the enumeration of protocols under the 'ianaAssigned' base layer (base layer value 5). At the time of publication, only 'ipxOverRaw8023' (value 1) is defined. New entries are submitted to the RMONMIB WG mailing list and collected at ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/.
This document discusses only the syntax and semantics of textual descriptions of networking protocols, not any networking behavior definition. As such, the authors state that no security considerations are raised by this memo.
The 802-1Q child layer-identifier is 4 octets: the first byte is a Base-ID distinguishing the following base encoding (0=ether2/snap, 2=llc, 4=vsnap, 5=ianaAssigned), and the remaining three bytes encode the base-layer-specific child identifier.
The base identifier is encoded as four octets [f, op1, op2, m]: the first octet ('f') is the special function code, the next two ('op1', 'op2') are operands (set to zero if unused), and the last octet ('m') is the enumerated base layer encapsulation value from Table 4.2.
The protocolDirID OCTET STRING is composed of one or more 4-octet layer-identifiers encoded in network byte order. The total length must be N*4 octets, where N is the number of protocol layers in the encapsulation.
The protocolDirParameters OCTET STRING contains exactly one 1-octet protocol-parameter per layer-identifier in protocolDirID. Its length must be exactly one quarter of the protocolDirID string length.