As per Relevance of the word parameter, we have this rfc below:
Network Working Group A.
Request for Comments: 2074 Cisco
Category: Standards Track R.
AXON Networks,Inc
January 1997
Remote Network Monitoring MIB Protocol
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
Table of
1 Introduction .................................................... 3
2 The SNMP Network Management Framework ........................... 3
2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 3
3.1 Terms ......................................................... 4
3.2 Relationship to the Remote Network Monitoring MIB ............. 6
3.3 Relationship to the Other MIBs ................................ 6
4 Protocol Identifier Encoding .................................... 7
4.1 ProtocolDirTable INDEX Format Examples ........................ 9
4.2 Protocol Identifier Macro Format .............................. 10
4.2.1 Mapping of the Protocol Name ................................ 12
4.2.2 Mapping of the VARIANT-OF Clause ............................ 13
4.2.3 Mapping of the PARAMETERS Clause ............................ 13
4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 14
4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 15
4.2.4 Mapping of the ATTRIBUTES Clause ............................ 15
4.2.5 Mapping of the DESCRIPTION Clause ........................... 15
4.2.6 Mapping of the CHILDREN Clause .............................. 16
4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 16
4.2.8 Mapping of the DECODING Clause .............................. 16
4.2.9 Mapping of the REFERENCE Clause ............................. 17
4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 17
5 Protocol Identifier Macros ...................................... 18
5.1 Base Identifier Encoding ...................................... 18
5.1.1 Protocol Identifier Functions ............................... 19
5.1.1.1 Function 0: No-op ......................................... 19
5.1.1.2 Function 1: Protocol Wildcard Function .................... 19
5.2 Base Layer Protocol Identifiers ............................... 20
5.2.1 Ether2 Encapsulation ........................................ 21
Bierman & Iddon Standards Track [Page 1]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.2 LLC Encapsulation ........................................... 22
5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 23
5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 24
5.2.5 IANA Assigned Protocols ..................................... 25
5.2.5.1 IANA Assigned Protocol Identifiers ........................ 27
5.3 L3: Children of Base Protocol Identifiers ..................... 27
5.3.1 IP .......................................................... 28
5.3.2 IPX ......................................................... 29
5.3.3 ARP ......................................................... 30
5.3.4 IDP ......................................................... 30
5.3.5 AppleTalk ARP ............................................... 31
5.3.6 AppleTalk ................................................... 31
5.4 L4: Children of L3 Protocols .................................. 32
5.4.1 ICMP ........................................................ 32
5.4.2 TCP ......................................................... 32
5.4.3 UDP ......................................................... 33
5.5 L5: Application Layer Protocols ............................... 33
5.5.1 FTP ......................................................... 33
5.5.1.1 FTP-DATA .................................................. 33
5.5.1.2 FTP Control ............................................... 34
5.5.2 Telnet ...................................................... 34
5.5.3 SMTP ........................................................ 34
5.5.4 DNS ......................................................... 35
5.5.5 BOOTP ....................................................... 35
5.5.5.1 Bootstrap Server Protocol ................................. 35
5.5.5.2 Bootstrap Client Protocol ................................. 35
5.5.6 TFTP ........................................................ 36
5.5.7 HTTP ........................................................ 36
5.5.8 POP3 ........................................................ 36
5.5.9 SUNRPC ...................................................... 37
5.5.10 NFS ........................................................ 38
5.5.11 SNMP ....................................................... 38
5.5.11.1 SNMP Request/Response .................................... 38
5.5.11.2 SNMP Trap ................................................ 39
6 Acknowledgements ................................................ 39
7 References ...................................................... 40
8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 43
Bierman & Iddon Standards Track [Page 2]
RFC 2074 RMON Protocol Identifiers January 1997
1.
This memo defines an experimental portion of the
Information Base (MIB) for use with network management protocols
the Internet community. In particular, it describes the
required to identify different protocol encapsulations managed
the Remote Network Monitoring MIB Version 2 [RMON2]. Although
to the original Remote Network Monitoring MIB [RFC1757],
document refers only to objects found in the RMON-2 MIB
2. The SNMP Network Management
The SNMP Network Management Framework presently consists of
major components. They are
o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used
describing and naming objects for the purpose of management
o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of
objects for the Internet suite of protocols
o the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905],
- the protocol for accessing managed information
Textual conventions are defined in RFC 1903 [RFC1903],
conformance statements are defined in RFC 1904 [RFC1904].
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
2.1. Object
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by
OBJECT IDENTIFIER, an administratively assigned name. The
type together with an object instance serves to uniquely identify
specific instantiation of the object. For human convenience,
often use a textual string, termed the descriptor, to refer to
object type
3.
The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs
globally identify individual protocol encapsulations in
protocolDirTable
Bierman & Iddon Standards Track [Page 3]
RFC 2074 RMON Protocol Identifiers January 1997
This guide contains algorithms and examples of protocol
encapsulations for use as INDEX values in the protocolDirTable
This document is not intended to be an authoritative reference on
protocols described herein. Refer to the Official Internet
document [RFC1800], the Assigned Numbers document [RFC1700], or
appropriate RFCs, IEEE documents, etc. for complete and
protocol information
3.1.
Several terms are used throughout this document, as well as in
RMON-2 MIB [RMON2], that should be introduced
layer-identifier
An octet string fragment representing a particular
encapsulation layer. A string fragment identifying a
protocol encapsulation layer. This string is exactly four octets
(except for the 'vsnap' base-layer identifier, which is
eight octets) encoded in network byte order. A particular
encapsulation can be identified by starting with a base
encapsulation (see the 'Base Protocol Identifiers' section for
detail), and following the encoding rules specified in the
clause and assignment section for that layer. Then repeat for
identified layer in the encapsulation. (See section 4.2.10
'Evaluating a Protocol-Identifier INDEX' for more detail.)
protocol
A particular protocol layer, as specified by encoding rules in
document. Usually refers to a single layer in a
encapsulation. Note that this term is sometimes used in the RMON-2
MIB [RMON2] to name a fully-specified protocol-identifier string
In such a case, the protocol-identifier string is named for
upper-most layer. A named protocol may also refer to
encapsulation of that protocol
protocol-identifier string
An octet string representing a particular protocol encapsulation
as specified by encoding rules in this document. This string
identified in the RMON-2 MIB [RMON2] as the protocolDirID object.
protocol-identifier string is composed of one or more layer
identifiers
Bierman & Iddon Standards Track [Page 4]
RFC 2074 RMON Protocol Identifiers January 1997
protocol-identifier macro
A group of formatted text describing a particular protocol layer
as used within the RMON-2 MIB [RMON2]. The macro serves
purposes
- Name the protocol for use within the RMON-2 MIB [RMON2].
- Describe how the protocol is encoded into an octet string
- Describe how child protocols are identified (if applicable),
and encoded into an octet string
- Describe which protocolDirParameters are allowed for the protocol
- Describe how the associated protocolDirType object is
for the protocol
- Provide reference(s) to authoritative documentation for
protocol
protocol-variant-identifier macro
A group of formatted text describing a particular protocol layer
as used within the RMON-2 MIB [RMON2]. This protocol is a
of a well known encapsulation that may be present in
protocolDirTable. This macro is used to document the
assigned protocols, which are needed to identify protocols
cannot be practically identified by examination of '
network traffic' (e.g. the packets which carry them). All
protocols (which can be identified by examination of
network traffic) should be documented using the protocol-
macro. A protocol-variant-identifier is documented using
protocol-variant version of the protocol-identifier macro
protocol-parameter
A single octet, corresponding to a specific layer-identifier in
protocol-identifier. This octet is a bit-mask indicating
functions or capabilities that this agent is providing for
corresponding protocol
protocol-parameters string
An octet string, which contains one protocol-parameter for
layer-identifier in the protocol-identifier. See the
'Mapping of the PARAMETERS Clause' for more detail. This string
identified in the RMON-2 MIB [RMON2] as the
object
protocolDirTable INDEX
A protocol-identifier and protocol-parameters octet string
that have been converted to an INDEX value, according to
encoding rules in in section 7.7 of RFC 1902 [RFC1902].
Bierman & Iddon Standards Track [Page 5]
RFC 2074 RMON Protocol Identifiers January 1997
pseudo-protocol
A convention or algorithm used only within this document for
purpose of encoding protocol-identifier strings
3.2. Relationship to the Remote Network Monitoring
This document is intended to identify possible string values for
OCTET STRING objects protocolDirID and protocolDirParameters.
in the new Protocol Distribution, Host, and Matrix groups use a
INTEGER INDEX, in order to remain unaffected by changes in
document. Only the protocolDirTable uses the strings (
and protocolDirParameters) described in this document
This document is not intended to limit the protocols that may
identified for counting in the RMON-2 MIB. Many
encapsulations, not explicitly identified in this document, may
present in an actual implementation of the protocolDirTable. Also
implementations of the protocolDirTable may not include all
protocols identified in the example section below
This document is intentionally separated from the MIB objects
allow frequent updates to this document without any republication
MIB objects. Protocol Identifier macros submitted from the
working group and community at large (to the RMONMIB WG mailing
at 'rmonmib@cisco.com') will be collected and added to this 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
"ftp://ftp.cisco.com/ftp/rmonmib/rmonmib".
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
'interesting' protocols--depending on the intended applications
3.3. Relationship to the Other
The RMON Protocol Identifiers document is intended for use with
protocolDirTable within the RMON MIB. It is not relevant to any
MIB, or intended for use with any other MIB
Bierman & Iddon Standards Track [Page 6]
RFC 2074 RMON Protocol Identifiers January 1997
4. 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 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
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, (except for
'vsnap' base layer) then it must be defined as a 'ianaAssigned
protocol (see below for details on IANA 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 & Iddon Standards Track [Page 7]
RFC 2074 RMON Protocol Identifiers January 1997
Fig. 1
protocolDirTable OCTET STRING
------------------------------------
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
+----------+
| |
| N octets |
| |
+----------+
Fig. 1
protocolDirTable INDEX Format
-------------------------------------
protocolDirID
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par
| n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 |
where N is the number of protocol-layer-identifiers
for the entire encapsulation of the named protocol. Note
the 'vsnap' base layer identifier is encoded into 8 sub-identifiers
All other protocol layers are either encoded into 4 sub-
or encoded as a 'ianaAssigned' protocol
Bierman & Iddon Standards Track [Page 8]
RFC 2074 RMON Protocol Identifiers January 1997
Fig. 1
protocolDirTable OCTET STRING Format
--------------------------------------------
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+
| 4 or 8 | 4 | 4 | 4 |
+---+---+---+---+
|par|par|par|par
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+
|1/2| 1 | 1 | 1 |
where N is the number of protocol-layer-identifiers
for the entire encapsulation of the named protocol. Note
the 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2
sub-identifiers
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].
Note that these two strings would not be concatenated together
ever returned in a GetResponse PDU, since they are different
objects. However, protocolDirID and protocolDirParameters are
currently readable MIB objects
4.1. ProtocolDirTable INDEX Format
-- 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
Bierman & Iddon Standards Track [Page 9]
RFC 2074 RMON Protocol Identifiers January 1997
-- 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(1)).snmp =
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
-- IPX over
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0
-- SNMP over UDP/IP over any link
-- wildcard-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
-- wildcard-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).
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
4.2. Protocol Identifier Macro
The following example is meant to introduce the protocol-
macro. (The syntax is not quite ASN.1.) This macro is used
represent both protocols and protocol-variants
If the 'VariantOfPart' component of the macro is present, then
macro represents a protocol-variant instead of a protocol.
protocol- variant-identifier is used only for IANA
protocols, enumerated under the 'ianaAssigned' base-layer
Bierman & Iddon Standards Track [Page 10]
RFC 2074 RMON Protocol Identifiers January 1997
RMON-PROTOCOL-IDENTIFIER MACRO ::=
PIMacroName "PROTOCOL-IDENTIFIER
"PARAMETERS"
"ATTRIBUTES"
"DESCRIPTION"
"::=" "{" EncapsPart "}"
PIMacroName ::=
VariantOfPart ::=
"VARIANT-OF" identifier |
ParamPart ::=
"{" ParamList "}"
ParamList ::=
Params |
Params ::=
Param | Params ","
Param ::=
identifier "(" nonNegativeNumber ")"
AttrPart ::=
"{" AttrList "}"
AttrList ::=
Attrs |
Attrs ::=
Attr | Attrs ","
Attr ::=
identifier "(" nonNegativeNumber ")"
ChildDescrPart ::=
"CHILDREN" Text |
AddrDescrPart ::=
"ADDRESS-FORMAT" Text |
Bierman & Iddon Standards Track [Page 11]
RFC 2074 RMON Protocol Identifiers January 1997
DecodeDescrPart ::=
"DECODING" Text |
ReferPart ::=
"REFERENCE" Text |
EncapsPart ::=
"{" Encaps "}"
Encaps ::=
Encap | Encaps ","
Encap ::=
BaseEncap | NormalEncap | VsnapEncap |
BaseEncap ::=
NormalEncap ::=
identifier
VsnapEncap ::=
identifier "(" nonNegativeNumber ")"
IanaEncap ::=
"ianaAssigned"
| "ianaAssigned"
| "ianaAssigned" identifier "(" nonNegativeNumber ")"
Text ::=
"""" string """"
4.2.1. Mapping of the Protocol
The 'PIMacroName' value should be a lower-case ASCII string,
contain the name or acronym identifying the protocol.
applications may treat protocol names as case-insensitive strings
and agent implementations must make sure the protocolDirTable
not contain any instances of the protocolDirDescr object which
only in the case of one of more letters (if the identifiers
intended to represent different protocols).
It is possible that different encapsulations of the same
(which are represented by different entries in the protocolDirTable
will be assigned the same protocol name
Bierman & Iddon Standards Track [Page 12]
RFC 2074 RMON Protocol Identifiers January 1997
A protocol name should match the "most well-known" name or
for the indicated protocol. For example, the document indicated
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
4.2.2. 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 reference protocol
identifier macro should not be duplicated in the protocol-variant
identifier macro, if the 'variant' protocols' semantics are
for a given clause
Since the PARAMETERS and ATTRIBUTES clauses must be present in
protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e
"PARAMETERS {}") must be present in a protocol-variant-
macro, and the 'ParamPart' and 'AttrPart' found in the
protocol- identifier macro examined instead
Note that if a '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
4.2.3. 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
Bierman & Iddon Standards Track [Page 13]
RFC 2074 RMON Protocol Identifiers January 1997
By convention, the following common bit definitions are used
different protocols. These bit positions must not be used for
parameters. They should be reserved if not used by a given protocol
Bits are encoded in network-byte order
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).
The PARAMETERS clause must be present in all protocol-
macro declarations, but may be equal to zero (empty). Note that
NMS must determine if a given PARAMETER bit is supported
attempting to create the desired protocolDirEntry The
ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do
exist
4.2.3.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 may 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 at most one protocolDirParameters octet
a protocolDirTable INDEX
Bierman & Iddon Standards Track [Page 14]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.3.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
4.2.4. 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
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
4.2.5. 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
Bierman & Iddon Standards Track [Page 15]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.6. 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
4.2.7. 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
4.2.8. 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
Bierman & Iddon Standards Track [Page 16]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.9. 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).
4.2.10. Evaluating a Protocol-Identifier
The following evaluation is done after 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 should be evenly divisible by four.
protocolDirParameters length should 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 may not be skipped, so identifiers such as 'SNMP over IP'
'TCP over anylink' 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. Refer to the '
Protocol Identifiers' section for wildcard encoding rules
After the protocol-tree identified in protocolDirID has been parsed
each parameter bit-mask (one octet for each 4-octet layer-identifier
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
Identifiers'),
Bierman & Iddon Standards Track [Page 17]
RFC 2074 RMON Protocol Identifiers January 1997
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.).
5. Protocol Identifier
The following PROTOCOL IDENTIFIER macros can be used to
protocolDirID and protocolDirParameters strings
The sections defining protocol examples are intended to grow
subsequent releases. Minimal protocol support is included at
time. (Refer to section 3.2 for details on the protocol macro
procedure.)
An identifier is encoded by constructing the base-identifier,
adding one layer-identifier for each encapsulated protocol
5.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
Bierman & Iddon Standards Track [Page 18]
RFC 2074 RMON Protocol Identifiers January 1997
5.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).
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)
5.1.1.1. Function 0: No-
If the function ID field (1st octet) is equal to zero, the 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
protocol identifier encoded in the remaining octets. The
represents a normal protocol encapsulation
5.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 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. If an encapsulation over 'ether2'
permitted, than this should be used as the base encapsulation
Bierman & Iddon Standards Track [Page 19]
RFC 2074 RMON Protocol Identifiers January 1997
The agent may also be requested to count some or all of
individual encapsulations for the same protocols, in addition
wildcard counting. Note that the RMON-2 MIB [RMON2] does not
that agents maintain counters for multiple encapsulations of the
protocol. It is an implementation-specific matter as to how an
determines which protocol combinations to allow in
protocolDirTable at any given time
5.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 ProtocolDirDescr field for the base layer is given
the corresponding "Name" field in the table 4.1 below. However
implementations are only required to use the appropriate
identifier values
For most base layer protocols, the protocolDirType field
contain bits set for the 'hasChildren(0)'
'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. New base encapsulations (e.g. for new media types) are
to be added over time
Table 4.2 Base Layer Encoding
--------------------------------------
Name
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
Bierman & Iddon Standards Track [Page 20]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.1. 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
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 MSB
LSB 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 are named as 'ether2' followed by the type
value in hexadecimal. The above example would be declared as
ether2 0x0800"
ADDRESS-
"Ethernet addresses are 6 octets in network order."
"Only type values greater than or equal to 1500 decimal
Ethernet-II frames; lower values indicate 802.3
(see below)."
"A Standard for the Transmission of IP Datagrams over
Networks; RFC 894 [RFC894].
The authoritative list of Ether Type values is identified by
URL
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
::= { 1 }
Bierman & Iddon Standards Track [Page 21]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.2. LLC
llc PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"The LLC (802.2) protocol."
"The LLC SSAP and DSAP (Source/Dest Service Access Points)
used to select child protocols. Each of these is one octet long
although the least significant bit is a control bit and should
masked out in most situations. Typically SSAP and DSAP (
masked) are the same for a given protocol - each end
knows whether it is the server or client in a client/
protocol. This is only a convention, however, and it is
for them to be different. The SSAP is matched against
protocols first. If none is found then the DSAP is
instead. The child protocol is deemed to start at the
octet after the LLC control field(s).
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 raw802.3
encapsulations). For 802.5 there is no other link
protocol
Bierman & Iddon Standards Track [Page 22]
RFC 2074 RMON Protocol Identifiers January 1997
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 }
5.2.3. SNAP over LLC (OUI=000)
snap PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
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 PID (Protocol Identifier) field 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 MSB and LSB of the Ethernet-II 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"
Bierman & Iddon Standards Track [Page 23]
RFC 2074 RMON Protocol Identifiers January 1997
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 OUI and two octets of PID. For this encapsulation
OUI must be 0x000000 (see '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 }
5.2.4. 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 do."
"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 ], the
identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ]
'a', 'b' and 'c' are the 3 octets of the OUI field in
byte order. This is in turn followed by the 16-bit
value, where the 'd' and 'e' represent the MSB and LSB of
EtherType, respectively
For example, a protocolDirID-fragment value of
0.0.0.4.0.8.0.7.0.0.128.155
defines the AppleTalk Phase 2 protocol over vsnap
Bierman & Iddon Standards Track [Page 24]
RFC 2074 RMON Protocol Identifiers January 1997
Note that two protocolDirParameters octets must be present
protocolDirTable INDEX values for 'vsnap' protocols. The
protocolDirParameters octet defines the actual parameters.
second protocolDirParameters octet is not used and must be set
zero
Children are named as 'vsnap() ', where
'' field is represented as 3 octets in hexadecimal
or the ASCII string associated with the OUI value.
field is represented by the 2 byte EtherType value
hexadecimal notation. So the above example would be named
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
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."
"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 }
5.2.5. 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
Bierman & Iddon Standards Track [Page 25]
RFC 2074 RMON Protocol Identifiers January 1997
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 'user-extensibility' feature of
protocolDirTable, and do not need special
assignments
A centrally located list of these enumerated protocols must
maintained to insure interoperability
(See section 3.2 for details on the document update procedure.)
Support for new link-layers will be added explicitly, and
protocols which cannot possibly be represented in a better
will be considered as 'ianaEnumerated' protocols
IANA assigned protocols are identified by the base-layer-
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of
integer 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
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 name or
of the particular IANA assigned protocol. The
example would be named
'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
"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 }
Bierman & Iddon Standards Track [Page 26]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.5.1. IANA Assigned Protocol
The following protocol-variant-identifier macro declarations are
to identify the RMONMIB IANA assigned protocols in a proprietary way
by simple enumeration. Note that an additional four-octet
identifier may be used for some enumerations (as with the 'vsnap
base-layer identifier). Refer to the 'CHILDREN' clause in
protocol-identifier macro for a particular protocol to determine
number of octets in the 'ianaAssigned' layer-identifier
ipxOverRaw8023 PROTOCOL-
VARIANT-OF "ipx
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 }
5.3. L3: Children of Base Protocol
Network layer protocol identifier macros contain
information about the network layer, and is found
following a base layer-identifier in a protocol identifier
The ProtocolDirParameters supported at the network layer
'countsFragments(0)', and 'tracksSessions(1). An agent may choose
implement a subset of these parameters
The protocol-name should be used for the ProtocolDirDescr field.
ProtocolDirType ATTRIBUTES used at the network layer
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents
choose to implement a subset of these attributes for each protocol
and therefore limit which tables the indicated protocol can
present (e.g. protocol distribution, host, and matrix tables)..
The following protocol-identifier macro declarations are given
example purposes only. They are not intended to constitute
exhaustive list or an authoritative source for any of the
Bierman & Iddon Standards Track [Page 27]
RFC 2074 RMON Protocol Identifiers January 1997
information given. However, any protocol that can encapsulate
protocols must be documented here in order to encode the
identifiers into protocolDirID strings. Leaf protocols should
documented as well, but an implementation can identify a
protocol even if it isn't listed here (as long as the parent
documented).
5.3.1.
ip PROTOCOL-
PARAMETERS {
countsFragments(0) -- This parameter applies to all
-- protocols
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"The protocol identifiers for the Internet Protocol (IP).
that IP may be encapsulated within itself, so more than one
the following identifiers may be present in a
protocolDirID string."
"Children of 'ip' are selected by the value in the Protocol
(one octet), as defined in the PROTOCOL NUMBERS table within
Assigned Numbers Document
The value of the Protocol field is encoded in an octet string
[ 0.0.0.a ], where 'a' is the protocol field .
Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a
where 'a' is the protocol field value. For example,
protocolDirID-fragment value of
0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-
"4 octets of the IP address, in network byte order. Each
packet contains two addresses, the source address and
destination address."
"Note: ether2/ip/ipip4/udp is a different protocolDirID
ether2/ip/udp, as identified in the protocolDirTable. As such
two different local protocol index values will be assigned by
agent. E.g. (full INDEX values shown):
ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
Bierman & Iddon Standards Track [Page 28]
RFC 2074 RMON Protocol Identifiers January 1997
"RFC 791 [RFC791] defines the Internet Protocol; The
URL defines the authoritative repository for the PROTOCOL
Table
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
ip 4,
ip 94
}
5.3.2.
ipx PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"Novell IPX
"Children of IPX are defined by the 16 bit value of
Destination Socket field. The value is encoded into an
string as [ 0.0.a.b ], where 'a' and 'b' are the network
order encodings of the MSB and LSB of the destination
field."
ADDRESS-
"4 bytes of Network number followed by the 6 bytes Host
each in network byte order".
"The IPX protocol is defined by the Novell
Bierman & Iddon Standards Track [Page 29]
RFC 2074 RMON Protocol Identifiers January 1997
A complete description of IPX may be secured at the
address
Novell, Inc
122 East 1700
P. O. Box 5900
Provo, Utah 84601
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}
5.3.3.
arp PROTOCOL-
PARAMETERS { }
ATTRIBUTES { }
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets,
are counted separately."
"RFC 826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
5.3.4.
idp PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"Xerox IDP
"Children of IDP are defined by the 8 bit value of the
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field
network byte order."
Bierman & Iddon Standards Track [Page 30]
RFC 2074 RMON Protocol Identifiers January 1997
ADDRESS-
"4 bytes of Network number followed by the 6 bytes Host
each in network byte order".
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}
5.3.5. AppleTalk
atalkarp PROTOCOL-
PARAMETERS { }
ATTRIBUTES { }
"AppleTalk Address Resolution Protocol."
"AppleTalk Phase 2 Protocol Specification, document
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f
}
5.3.6.
atalk PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
"AppleTalk Protocol."
"Children of ATALK are defined by the 8 bit value of the DDP
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network
order."
ADDRESS-
"2 bytes of Network number followed by 1 byte of node id each
network byte order".
Bierman & Iddon Standards Track [Page 31]
RFC 2074 RMON Protocol Identifiers January 1997
"AppleTalk Phase 2 Protocol Specification, document
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809
}
5.4. L4: Children of L3
5.4.1.
icmp PROTOCOL-
PARAMETERS { }
ATTRIBUTES { }
"Internet Message Control Protocol."
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 }
5.4.2.
tcp PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
"Transmission Control Protocol."
"Children of TCP are identified by the 16 bit Destination
value as specified in RFC 793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination
value. Both bytes are encoded in network byte order.
example, a protocolDirId-fragment of
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet
(ether2.ip.tcp.telnet)"
"RFC 793 [RFC793] defines the Transmission Control Protocol
The following URL defines the authoritative repository
reserved and registered TCP port values
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
::= { ip 6 }
Bierman & Iddon Standards Track [Page 32]
RFC 2074 RMON Protocol Identifiers January 1997
5.4.3.
udp PROTOCOL-
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
"User Datagram Protocol."
"Children of UDP are identified by the 16 bit Destination
value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the 