WDIFF

draft-ietf-rmonmib-rmonprot-00.txt --> draft-ietf-rmonmib-rmonprot-01.txt

view Side-By-Side changes

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

Remote Network Monitoring MIB Protocol Identifiers
<draft-ietf-rmonmib-rmonprot-00.txt>

17 November 1995
<draft-ietf-rmonmib-rmonprot-01.txt>

22 January 1996

Andy Bierman
Bierman Consulting
abierman@west.net

Robin Iddon
AXON Networks, Inc.
robini@axon.com

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Bierman/Iddon Expires May 17, July 22, 1996 [Page 1]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

1. Introduction

This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes the algorithms required to
identify different protocol encapsulations managed with the Remote
Network Monitoring MIB Version 2 (RMON-2) [RMON2]. Although related to
the original Remote Network Monitoring MIB (RMON) [RFC1757], this
document refers only to objects found in the RMON-2 MIB.

1.1. The SNMPv2 SNMPv1 Network Management Framework

The SNMPv2 SNMPv1 Network Management Framework presently consists of four two major
components. They are:

o RFC 1442 [RFC1442] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.

o STD 17, RFC 1213 [RFC1213] defines MIB-II, the core set of managed
objects for the Internet suite of protocols.

o RFC 1445 [RFC1445] which defines the administrative and other
architectural aspects of the framework.

o RFC 1448 [RFC1448] which defines the protocol used for network
access to managed objects.

The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.

1.1.1. Object Definitions

Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the
SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
an administratively assigned name. The object type together with an
object instance serves to uniquely identify a specific instantiation of
the object. For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 2]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

2. Overview

The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to
globally identify specific individual protocol encapsulations in the
protocolDirTable.

This guide contains algorithms and examples of protocol identifier
encapsulations for use as INDEX values in the protocolDirTable.

This document is not intended to be an authoritative reference on the
protocols described herein. Refer to the Official Internet Standards
document (RFC 1800) [RFC1800], the Assigned Numbers document (RFC 1700)
[RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete
and authoritative protocol information.

2.1. Terms

Several terms are used throughout this document, as well as in the
RMON-2 MIB [RMON2], that should be introduced:

layer-identifier:
An octet string fragment representing a particular protocol
encapsulation layer. A layer-identifier is composed of one or more
layer-identifier-components. An implementation must recognize the
number of layer-identifier-components in a non-standard way, since
there is no layer-identifier-component-count octet encoded into a
protocol-identifier string.

layer-identifier-component:
A four-octet string fragment identifying some or all of a
particular protocol encapsulation layer. This string is always exactly
four octets in length and octets, (except for the 'vsnap' pseudo-MAC-layer identifier,
which is exactly eight octets) encoded in network byte order. A
particular protocol encapsulation can be identified by starting
with a MAC layer encapsulation (see the 'L2 Protocol Identifiers'
section for more detail), and following the encoding rules
specified in the CHILDREN clause and assignment section for that
layer. Then repeat for each identified layer in the encapsulation.
(See the section 'Evaluating a Protocol-Identifier INDEX' for more
detail.)

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

Bierman/Iddon Expires May 17, 1996 [Page 3]

Draft RMON Protocol Identifiers November 17, 1995
MIB [RMON2] 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.

Bierman/Iddon Expires July 22, 1996 [Page 3]

Draft RMON Protocol Identifiers January 22, 1996

protocol-identifier string:
An octet string representing a particular protocol encapsulation,
as specified by encoding rules in this document. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
protocol
protocol-identifier string is composed of one or more
layer-identifiers. layer-
identifiers.

protocol-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. The macro serves several
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 encoded
for the protocol.
- Provide reference(s) to authoritative documentation for the
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 variant
of a well known encapsulation that may be present in the
protocolDirTable. This macro is used to document the working group
assigned protocols. All other protocols should be documented using
the protocol-identifier macro.

protocol-parameter:
A single octet, corresponding to a specific layer-identifier-
component 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.

protocol-parameters string:
An octet string, which contains one protocol-parameter for each
layer-identifier-component
layer-identifier in the protocol-identifier. See the section
'Mapping of the PARAMETERS Clause' for more detail. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
object.

protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair

Bierman/Iddon Expires July 22, 1996 [Page 4]

Draft RMON Protocol Identifiers January 22, 1996

that have been converted to an INDEX value, according to the
encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212].

Bierman/Iddon Expires May 17, 1996 [Page 4]

Draft RMON Protocol Identifiers November 17, 1995

pseudo-protocol:
A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings.

2.2. Relationship to the Remote Network Monitoring MIB

This document is intended to identify possible string values for the
OCTET STRING objects protocolDirID and protocolDirParameters. Tables in
the new Protocol Distribution, Host, and Matrix groups use a local
INTEGER INDEX, in order to remain unaffected by changes in this
document. Only the protocolDirTable uses the strings (protocolDirID and
protocolDirParameters) described in this document.

This document is not intended to limit the protocols that may be
identified for counting in the RMON-2 MIB. Many protocol encapsulations,
not explicitly identified in this document, may be present in an actual
implementation of the protocolDirTable. Also, implementations of the
protocolDirTable may not include all the protocols identified in the
example section below.

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 'interesting'
protocols--depending on the intended applications.

2.3. Relationship to the Other MIBs

The RMON Protocol Identifiers 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.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 5]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

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 4.1.6 of STD 16 (RFC 1212) [RFC1212]. 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 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 one or more a single 32-bit values. value. Each
layer-identifier-value
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.

Notice that each encapsulating layer may use one or more of these If a particular protocol layer
identifiers to indicate
cannot be encoded into 32 bits, (except for the encapsulated protocol. However, there are no
actual cases included in this document where this was required. An
implementation 'vsnap' MAC layer) then
it must determine how many layer-identifiers be defined as a 'wgAssigned' protocol (see below for details on
working group assigned protocols).

Bierman/Iddon Expires May 17, July 22, 1996 [Page 6]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

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
------------------------------------

Fig. 1c
protocolDirTable INDEX Format Detail
------------------------------------ Example
-------------------------------------

protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | L2 | L3 | L4 | L5 | n | L2| L3| L4| L5|
| t | | |(+flags)| | | | t | | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 * N2 or 8 | 4 * N3 | 4 * N4 | 4 * N5 | 1 |1/2| 1 | 1 | 1 | N2| N3| N4| N5| count

where Ni N is the number of protocol-layer-values protocol-layer-identifiers required
for protocol layer 'i', and 'subOID' is a single the entire encapsulation of the named protocol. Note that

Bierman/Iddon Expires May 17, July 22, 1996 [Page 7]

Draft RMON Protocol Identifiers November 17, 1995

OBJECT IDENTIFIER sub-identifier. January 22, 1996

the 'vsnap' MAC layer identifier is encoded into 8 sub-identifiers,
All other protocol layers are either encoded into 4 sub-identifiers
or encoded as a 'wgAssigned' protocol.

Fig. 1d
protocolDirTable OCTET STRING Format Detail
------------------------------------------- Example
--------------------------------------------

protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| L2 | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 * N2 or 8 | 4 * N3 | 4 * N4 | 4 * N5 | count

protocolDirParameters
+---+---+---+---+
|par|par|par|par|
| L2| L3| L4| L5|
| | | | |
+---+---+---+---+ octet
|1/2| 1 | 1 | 1 | N2| N3| N4| N5| count

where Ni N is the number of protocol-layer-values protocol-layer-identifiers required
for protocol layer 'i'. the entire encapsulation of the named protocol. Note that these two strings would not be
concatenated together if ever returned in a GetResponse PDU,
since they are different MIB objects. (However,
the 'vsnap' MAC layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters are not currently readable MIB objects.)
sub-identifiers.

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 7.1.3 of RFC 1442 [RFC1442].

Note that these two strings would not be concatenated together if ever
returned in a GetResponse PDU, since they are different MIB objects.
However, protocolDirID and protocolDirParameters are not currently
readable MIB objects.

Bierman/Iddon Expires July 22, 1996 [Page 8]

Draft RMON Protocol Identifiers January 22, 1996

3.1. ProtocolDirTable INDEX Format Examples

-- 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

Bierman/Iddon Expires May 17, 1996 [Page 8]

Draft RMON Protocol Identifiers November 17, 1995

-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.0.161.3.0.0.0
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0

-- SNMP over IPX over raw8023
raw8023.ipx.snmp
-- wgAssigned(ipxOverRaw8023(1)).snmp =
12.0.0.0.5.0.0.129.55.0.0.0.161.3.0.0.0
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0

-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0

-- SNMP over UDP/IP over any link layer
-- wildcard-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

-- LLC 'others' pseudo-protocol
4.0.0.0.2.1.2

-- IP over any link layer 'others' pseudo-protocol layer; base encoding is IP over ether2
-- wildcard-ether2.ip
8.2.1.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
-- wildcard-ether2.ip(others)
8.1.0.0.1.0.0.8.0.2.0.2 vsnap(apple).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 syntax. protocol-identifier and
protocol-variant-identifier macros. The syntax is not ASN.1; The
definitive BNF definitions for the protocol-identifier macro syntax can
be found in Appendix A.

Bierman/Iddon Expires July 22, 1996 [Page 9]

Draft RMON Protocol Identifiers January 22, 1996

A protocol-variant-identifier is used only for working group assigned
protocols, enumerated under the 'wgAssigned' pseudo-MAC-layer tree.

protocol-identifier :==
<protocol-name> "PROTOCOL-IDENTIFIER"
"PARAMETERS" "{" <param-bit-list> "}"
"ATTRIBUTES" "{" <attrib-bit-list> "}"
"DESCRIPTION" """ <protocol-description> """
[ "CHILDREN" """ <children-description> """ ]
[ "ADDRESS-FORMAT" """ <address-format-description> """ ]
[ "DECODING" """ <decoding-description> """ ]
[ "REFERENCE" """ <reference-description> """ ]
"::=" "{" <protocol-encoding-identifiers> "}"

protocol-variant-identifier :==
<protocol-variant-name> "PROTOCOL-VARIANT-IDENTIFIER"
"VARIANT-OF" """ <protocol-name> """
[ "PARAMETERS" "{" <param-bit-list> "}" ]
[ "ATTRIBUTES" "{" <attrib-bit-list> "}" ]
"DESCRIPTION" """ <protocol-description> """
[ "CHILDREN" """ <children-description> """ ]
[ "ADDRESS-FORMAT" """ <address-format-description> """ ]
[ "DECODING" """ <decoding-description> """ ]
[ "REFERENCE" """ <reference-description> """ ]
"::=" "{" <protocol-encoding-identifiers> "}"

3.2.1. Mapping of the Protocol Name

The 'protocol-name' value must be an lower-case ASCII string, and if
possible, should match the "most well-known" name or acronym for the

Bierman/Iddon Expires May 17, 1996 [Page 9]

Draft RMON Protocol Identifiers November 17, 1995
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.

3.2.2. Mapping of the Protocol Variant Name

The 'protocol-variant-name' value must be an lower-case ASCII string,
and must match the working group assigned name for that protocol. For

Bierman/Iddon Expires July 22, 1996 [Page 10]

Draft RMON Protocol Identifiers January 22, 1996

'wgAssigned' protocols, the enumeration identifier should be used as the
protocol-variant-name for the indicated protocol.

3.2.3. 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 conformant 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 should be reserved if not used by a given protocol.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 10] 11]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

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 others this parameter is used to identify a 'pseudo-
protocol' -- the children of the protocol
encapsulation identified by the protocolDirID
portion of the INDEX, which are not otherwise
identified by entries in the protocolDirTable.
This is a valid parameter for all extensible
protocols.
2 trackSessions 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 empty.

3.2.2.1. equal to zero (empty). Note that an NMS must
determine if a given PARAMETER bit is supported by attempting to create
the desired protocolDirEntry The associated ATTRIBUTE bits for
'countsFragments' and 'tracksSessions' do not exist.

3.2.3.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 may 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 at most one protocolDirParameter protocolDirParameters octet within a
protocolDirTable INDEX.

Bierman/Iddon Expires May 17, 1996 [Page 11]

Draft RMON Protocol Identifiers November 17, 1995

3.2.2.2.

3.2.3.2. Mapping of the 'others(1)' 'tracksSessions(1)' BIT

The 'others(1)' BIT is handled in a special way. The unique OCTET
STRING created with the others(1) bit set in the last
protocolDirParameters octet identifies the 'others' pseudo-protocol.
Note that corresponding protocolDirEntry, (i.e. identical, but without
the 'others' bit set), may or may not be present in the
protocolDirTable.

Only the un-attributed protocols ('others') counters are kept for this
pseudo-protocol. If the unknown protocol occurs above the network layer,
then host and matrix entries can be maintained for the 'others' entry,
otherwise only a protocol distribution entry can be kept. Only the last
protocol specified in the protocolDirID can set the 'others' bit in the
corresponding protocolDirParameters octet.

For example, to indicate all unknown ETHER TYPES, the protocol
identifier '4.0.0.0.1.1.2' would be used. An agent might assign this
protocol a local index value of '42'. After creating the appropriate
control entry, protocolDistStatsPkts.1.42 would contain the unknown
ETHER TYPES packet count, and protocolDistStatsOctets.1.42 would contain
the unknown ETHER TYPES octet count.

The following examples show identifiers for 'ip(others)' and
'tcp(others)'

ether2.ip(others) = 8.0.0.0.1.0.0.8.0.0.2.0.2

ether2.ip.tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.0.2

-- the following identifier is illegal
ether2.ip(others).tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.2.2

3.2.2.2.1. Relationship to the protocolDirTable

The protocol-collection control objects (e.g. protocolDirHostConfig) can
affect the overall consistency of counter values retrieved by a
management station, since collection of given protocols can be enabled
or disabled while collection is running. Also, protocols may be added to
the protocolDirTable while collections are in progress.

The following 'counting' rules must be implemented by a probe to ensure
that consistent data is returned to the management station:

Bierman/Iddon Expires May 17, 1996 [Page 12]

Draft RMON Protocol Identifiers November 17, 1995

- If collection of a child protocol is disabled in a given table with
one of the protocolDir*Config objects, then the counts for this
protocol are 'conceptually' added to the 'parent-protocol' counter,
if that protocol is being counted. This action must be transparent
to the management station, since counters for the parent-protocol
cannot be affected by configuration switches for upper-layer
protocols.

- If collection of a child protocol is enabled at some time after
collection of 'others' counts for the parent has begun, (either
because some instance of protocolDir*Config was changed or a new
protocolDirEntry was created), then the probe must ensure that all
counter values are consistent after the child protocol collection
begins. An RMON-2 probe is required to instantiate counters with a
value of zero, which should be enough to meet this requirement.

3.2.2.3. Mapping of the 'tracksSessions(2)' BIT

The 'tracksSessions(2)' '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

Bierman/Iddon Expires July 22, 1996 [Page 12]

Draft RMON Protocol Identifiers January 22, 1996

packets received on the indicated interface, and maintain some state
information, (e.g. the remapped UDP port number for TFTP).

The semantics of the 'trackSessions' 'tracksSessions' parameter are independent of the
other protocolDirParameter protocolDirParameters definitions, so this parameter may be
combined with any other legal parameter configurations.

3.2.3.

3.2.4. Mapping of the VARIANT-OF Clause

This clause is present for working group assigned protocols only. It
identifies the protocol-identifier macro that most closely represents
this particular protocol. Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in
the referenced protocol-identifier macro should not be duplicated in the
protocol-variant-identifier macro, if the 'variant' protocols' semantics
are identical for a given clause.

Note that if a 'wgAssigned' 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 macro.

3.2.5. 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 directly encoded
into the associated instance of ProtocolDirType. The BIT definitions are
specified in the SYNTAX clause of the protocolDirType MIB object.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 13]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

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.4.

3.2.6. 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.5.

3.2.7. 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.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 14]

Draft RMON Protocol Identifiers November 17, 1995

3.2.6. January 22, 1996

3.2.8. 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.7.

3.2.9. 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 ('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.8.

3.2.10. 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 already currently be obtained from an
'authoritative' document, such as the Assigned Numbers document (RFC
1700) [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).

Bierman/Iddon Expires May 17, July 22, 1996 [Page 15]

Draft RMON Protocol Identifiers November 17, 1995

3.2.9. January 22, 1996

3.2.11. Evaluating a Protocol-Identifier INDEX

The following evaluation is done after protocolDirTable INDEX value has
been converted into two OCTET STRINGs according to the INDEX encoding
rules specified in RFC 1212.

Protocol-identifiers are evaluated left-to-right, left to right, starting with the
protocolDirID, which length should be evenly divisible by four. The
protocolDirParameters length should be exactly one quarter of the
protocolDirID string length.

Protocol-identifier parsing starts with the MAC 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 may not be
skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can
not exist.

The MAC-layer-identifier also contains a 'special function identifier'
which may apply to the rest of the protocol identifier.

Wild-carding at th MAC layer within a protocol encapsulation is the only
supported special function at the MAC layer (see this time. Refer to the 'L2 Protocol
Identifiers' section for MAC-wildcard details). 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-
component) layer-identifier) is
evaluated, and applied to the corresponding protocol layer. Note that the 'others(1)' BIT may only be set once in a
protocolDirParameters string, and that this has to occur in the last
octet of the string. This bit is only applicable for protocols in which
the 'hasChildren' ATTRIBUTE bit is set. An agent should reject
SetRequests in which the 'others(1)' bit in protocolDirParameters is set
in any other manner.

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'),

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 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. encapsulation (e.g. ip over ether2,
ip over LLC, etc.).

Bierman/Iddon Expires May 17, July 22, 1996 [Page 16]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

4. Protocol Identifier Macro Examples Macros

The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParmaters protocolDirParameters strings.

This section is

The sections defining protocol examples are intended to grow over time.
subsequent releases. Minimal protocol support is included at this time.

4.1. L2 Protocol Identifiers

The first layer (L2) is mandatory, and defines time.

An identifier is encoded by constructing the base-identifier, then
adding one layer-identifier for each encapsulated protocol.

4.1. Base Identifier Encoding

The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the 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 MAC 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
MAC layer encapsulation identifier.

The first three octets of the packet. identifier contain the function code and
two optional operands. The fourth octet contains the particular MAC

Bierman/Iddon Expires July 22, 1996 [Page 17]

Draft RMON Protocol Identifiers January 22, 1996

layer encapsulation is encoded used in an octet string as
a 4-octet this protocol (fig. 2).

By design, only 255 different MAC layer identifier, of encapsulations are supported.
There are five encapsulation values defined at this time.

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. Normal Encoding: No Functions Selected

If the form:

w.0.a.b

where 'w' function ID field (1st octet) is equal to zero, the 'anylink' wildcard indicator, the 'op1' and 'a'
'op2' fields (2nd and 'b' 3rd octets) must also be equal to zero. This
special value indicates that no functions are applied to the
network byte order encodings of the MSB and LSB of the "ID" field protocol
identifier encoded in
table below. the remaining octets. The identifier represents a
single protocol encapsulation.

4.1.1.2. Protocol Wildcard Function

The wildcard indicator (0==no wildcard, 1==wildcard), function (function-ID = 1), is used to flag
the special pseudo-MAC-layer for the purpose aggregate counters,
by using a single protocol value to indicate potentially many MAC layer
encapsulations of a particular network layer protocol. A
protocolDirEntry of this type will match any MAC-layer encapsulation of aggregating counts.

If
the wildcard flag same protocol.

The 'op1' field (2nd octet) is not used and must be set in an protocol identifier, then the
encapsulation given in 'a.b', (called the 'base encapsulation') to zero.

The 'op2' field (3rd octet) is not used
simply and must be set to identify the rest of the zero.

Each wildcard protocol layers. identifier must be defined in terms of a 'base
encapsulation'. This base
encapsulation should be the 'ether2' encapsulation, if possible.

Note that only one net-layer-encapsulation is actually encoded into the
protocol identifier. An agent will need to identify other encapsulations
of the indicated network-layer protocol in as 'standard' as possible for
interoperability purposes. If an implementation-specific
manner, and count all matching encapsulations which are part of encapsulation over 'ether2' is
permitted, than this
'wildcard' protocol. should be used as the 'base encapsulation'.

The agent may also be requested to count some or all of the individual
encapsulations for the same protocols, in addition to wildcard counting.

There
Note that the RMON-2 MIB does not require that agents maintain counters
for multiple encapsulations of the same protocol. It is one value an

Bierman/Iddon Expires July 22, 1996 [Page 18]

Draft RMON Protocol Identifiers January 22, 1996

implementation-specific matter as to how an agent determines which
protocol combinations to allow in the protocolDirTable at any given
time.

4.2. L2 Protocol Identifiers

The first layer (L2) is mandatory, and defines the MAC encapsulation of
the packet and any special functions for this identifier.

There are no suggested protocolDirParameters defined bits for the MAC layer
at this time; the 'others' counter can be supported at this layer.

The suggested ProtocolDirDescr field for the MAC layer is given by the
corresponding "Name" field in the table 4.1 below. However,
implementations may choose different are only required to use the appropriate integer
identifier values.

Bierman/Iddon Expires May 17, 1996 [Page 17]

Draft RMON Protocol Identifiers November 17, 1995

The MAC layer protocolDirType field should contain bits set for the
"hasChildren(0)"
'hasChildren(0)' and "addressRecognitionCapable(1)" attributes. 'addressRecognitionCapable(1)' attributes, except
for the special 'wgAssigned' list, which should have no parameter or
attribute bits set.

Table 4.1 4.2 MAC Layer Encoding Values
-------------------------------------

Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
raw8023
wgAssigned 5

4.1.1.

4.2.1. Ether2 Encapsulation

ether2 PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of ether2 packets that didn't match
-- any children of ether2 enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION

Bierman/Iddon Expires July 22, 1996 [Page 19]

Draft RMON Protocol Identifiers January 22, 1996

"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.

Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the MSB and
LSB of the Ethernet-II type value.

For example, a protocolDirID protocolDirID-fragment value of:

8.0.0.0.1.0.0.8.0
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.

Children of are named as 'ether2' followed by the type field

Bierman/Iddon Expires May 17, 1996 [Page 18]

Draft RMON Protocol Identifiers November 17, 1995
value in hexadecimal. The above example would be declared as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)."
REFERENCE
"RFC 894;
The authoritative list of Ether Type values is identified
by the URL:

ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }

4.1.2.

4.2.2. LLC Encapsulation

llc PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of llc packets that didn't match
-- any children of llc enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The LLC (802.2) protocol."
CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) are
used to select child protocols. Each of these is one octet long,

Bierman/Iddon Expires July 22, 1996 [Page 20]

Draft RMON Protocol Identifiers January 22, 1996

although the least significant bit is a control bit and should be
masked out. out in most situations. Typically SSAP and DSAP (once
masked) are the same for a given protocol - each end implicitly
knows whether it is the server or client in a client/server
protocol. This is only a convention, however, and it is possible
for them to be different. The SSAP is matched against child
protocols first. If none is found then the DSAP is matched
instead. The child protocol is deemed to start at the first
octet after the LLC control field(s).

Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier for LLC followed by [ 0.0.0.a ] where 'a' is the SAP

Bierman/Iddon Expires May 17, 1996 [Page 19]

Draft RMON Protocol Identifiers November 17, 1995
value which maps to the child protocol. For example, a
protocolDirID
protocolDirID-fragment value of:

8.0.0.0.2.0.0.0.240
0.0.0.2.0.0.0.240

defines NetBios over LLC.

Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.

LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw802.3
encapsulations). For 802.5 there is no other link layer
protocol.

Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"IEEE 802.2 - [TBD]

The authoritative list of LLC LSAP values is controlled by the IEEE
Registration Authority:

Bierman/Iddon Expires July 22, 1996 [Page 21]

Draft RMON Protocol Identifiers January 22, 1996

IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }

Bierman/Iddon Expires May 17, 1996 [Page 20]

Draft RMON Protocol Identifiers November 17, 1995

4.1.3. { 2 }

4.2.3. SNAP over LLC (OUI=000) Encapsulation

snap PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of snap packets that didn't match
-- any children of snap enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP PID (Protocol Identifier) field is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.

Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
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 protocolDirID-fragment value of:

8.0.0.0.3.0.0.8.0
0.0.0.3.0.0.8.0

defines the IP/SNAP protocol.

Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:

snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING

Bierman/Iddon Expires July 22, 1996 [Page 22]

Draft RMON Protocol Identifiers January 22, 1996

"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of OUI and two octets of PID. For this encapsulation the
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
REFERENCE
"[TBD]"

Bierman/Iddon Expires May 17, 1996 [Page 21]

Draft RMON Protocol Identifiers November 17, 1995
::= { 3 }

4.1.4.

4.2.4. SNAP over LLC (OUI != 000) Encapsulation

vsnap PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of vsnap packets that didn't match
-- any children of vsnap enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that do."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet.

Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
identifier for 'vsnap', followed by [ 0.a.b.c 0.a.b.c.0.0.d.e ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order. This is in turn followed by the 16-bit EtherType
value, where the 'd' and 'e' represent the MSB and LSB of the
EtherType, respectively.

For example, a protocolDirID protocolDirID-fragment value of:

8.0.0.0.4.0.1.2.3
0.0.0.4.0.8.0.7.0.0.128.155

defines the set of protocols whose OUI Appletalk Phase 2 protocol over vsnap.

Note that two protocolDirParameters octets must be present in
protocolDirTable INDEX values for 'vsnap' protocols. The first
protocolDirParameters octet defines the actual parameters. The
second protocolDirParameters octet is 0x010203. not used and must be set to
zero.

Children are named as 'vsnap' followed by 'vsnap(<OUI>) <ethertype>', where the

Bierman/Iddon Expires July 22, 1996 [Page 23]

Draft RMON Protocol Identifiers January 22, 1996

'<OUI>' field is represented as 3 octets of in hexadecimal notation
or the ASCII string associated with the OUI
as a single hexadecimal value. The
<ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named:

vsnap 0x010203"

'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'

ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero."
REFERENCE
"Same as for 'snap'."
::= { 4 }

Bierman/Iddon Expires May 17, 1996 [Page 22]

Draft RMON Protocol Identifiers November 17, 1995

4.1.5. Raw 802.3 Encapsulation

4.2.5. Working Group Assigned Protocols

wgAssigned PROTOCOL-IDENTIFIER
PARAMETERS {
}
ATTRIBUTES {
}
DESCRIPTION
This really only here branch contains protocols which do not conform easily to support Novell's older encapsulation on
-- ethernet-like LANs. the
hierarchical format utilized in the other link layer branches.
Do not create children of this protocol unless
-- you are sure that
they cannot be handled by the more conventional link
-- layers
above.
raw8023 PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of raw8023 packets that didn't match
-- Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
identification criteria are used, preventing any children of raw8023 enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol describes an 802.3 header (destination,
source, length) 'well-known'
protocol-identifier macro from being used.

Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with no LLC/802.2 header. This encapsulation
violates the 802.3 specification in that 'user-extensibility' feature of the 802.2 header is
mandated for 802.3 frames. The header is otherwise well formed."
CHILDREN
"Children
protocolDirTable, and do not need special working group
assignments.

A centrally located list of 'raw8023' these enumerated protocols must be
maintained by the RMON working group [ed-- or perhaps IANA] to
insure interoperability. Support for new link-layers will be
added explicitly, and only protocols which cannot possibly be
represented in a better way will be considered.

Bierman/Iddon Expires July 22, 1996 [Page 24]

Draft RMON Protocol Identifiers January 22, 1996

Working group protocols are identified by the Ethernet-II type
field MAC-layer-selector
value which they would use if running over [ 0.0.0.5 ], followed by the 'snap' or
'ether2' link layer protocols. In reality there is no such field
in four octets [ a.b.c.d ] of the packet; instead
integer value corresponding to the agent decodes particular WG protocol.

[ed--the WG must decide if the header and maps it
to this value in list should be maintained as a protocol specific manner. MIB
object
anyway. The child protocol enumerated list is deemed to start at the first octet after the 802.3 length
field (i.e. included below in the information field).

Children meantime.]"
CHILDREN
"Children of 'raw8023' are encoded as [ 0.0.0.5 ], the this protocol
identifier for 'raw8023', followed by [ 0.0.a.b ] where 'a' and
'b' are identified by implementation-
specific means, described (as best as possible) in the MSB and LSB of 'DECODING'
clause within the Ethernet-II type. 'PSEUDO-PROTOCOL-IDENTIFIER' for each
enumerated protocol.

For example, a
protocolDirID protocolDirID-fragment value of:

8.0.0.0.5.0.0.129.55
0.0.0.5.0.0.0.1

defines the IPX protocol encapsulated directly in 802.3. 802.3

Children are named 'raw8023' 'wgAssigned' followed by the value name and value of
the particular enumeration in ASCII Ethernet-II type in
hexadecimal. The above example would be named:

'wgAssigned ipxOverRaw8023(1)'"
DECODING
"The 'wgAssigned' link layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER and PROTOCOL-VARIANT-IDENTIFIER
macros for information on each child of the wgAssigned protocol."
::= { 5 }

-- RMON Working Group Enumerated Protocol Assignments
-- Add new enumerations to the end of the
Ethernet-II type list only
-- Add one protocol-variant-identifier macro for each enumeration
wgAssignedProtocols OBJECT-TYPE
MAX-ACCESS not-accessible
STATUS current
SYNTAX INTEGER {
ipxOverRaw8023(1)
}
DESCRIPTION
"This enumerated list contains identifiers used in hexadecimal. The above example would be
named:

raw8023 0x8137"
ADDRESS-FORMAT
"The address format is the same as that for 'ether2'."
naming of protocolDirTable entries."
REFERENCE

Bierman/Iddon Expires May 17, July 22, 1996 [Page 23] 25]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

"Each enumerated protocol is identified in the RMON Protocol
Identifiers document [rfcxxxx]."
::= { rmon xxx }

4.2.6. Working Group Enumerated Protocol Identifiers

The following protocol encapsulations are identified by the RMON WG in a
proprietary way, by simple enumeration.

ipxOverRaw8023 PROTOCOL-VARIANT-IDENTIFIER
VARIANT-OF "ipx"
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.

Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
REFERENCE
"None - this is a pseudo-protocol."
::= { 5 wgAssigned 1 }

4.2.

4.3. L3 Protocol Identifiers

Network layer protocol identifier macros contain additional information
about the network layer, and (if present) is found immediately following an L2
layer-identifier in a protocol identifier.

The ProtocolDirParameters supported at the network layer are
'countsFragments(0)', 'others(1)', and 'tracksSessions(2). 'tracksSessions(1). An agent may choose to
implement a subset of these parameters.

The protocol-name should be used for the ProtocolDirDescr field. The
ProtocolDirType ATTRIBUTES used at the network layer are
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose
to implement a subset of these attributes, attributes for each protocol, and
therefore limit which tables the indicated protocol can be present (e.g. protocolDistribution,
nlHost, nlMatrix)..
protocol distribution, host, and matrix tables)..

Bierman/Iddon Expires July 22, 1996 [Page 26]

Draft RMON Protocol Identifiers January 22, 1996

The following protocol-identifier macro declarations are given for
example purposes only. They are not intended to constitute an exhaustive
list or an authoritative source for any of the protocol information
given.

4.2.1. However, any protocol that can encapsulate other protocols must
be documented here in order to encode the children identifiers into
protocolDirID strings. Leaf protocols should be documented as well, but
an implementation can identify a leaf protocol even if it isn't listed
here (as long as the parent is documented).

4.3.1. IP

ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0), -- This parameter applies to all child
-- protocols.
others(1) -- The count of ip packets that didn't match
-- any children of ip enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),

Bierman/Iddon Expires May 17, 1996 [Page 24]

Draft RMON Protocol Identifiers November 17, 1995
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for IP. " the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of IP 'ip' are defined selected by the value in the Protocol field, field
(one octet), as defined in the PROTOCOL NUMBERS table within the
Assigned Numbers Document.

The value of the Protocol field is encoded in an octet string as
[ 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 'a' is the protocol field value. For example, a
protocolDirID-fragment value (in
decimal)." of:
0.0.0.1.0.0.8.0.0.0.0.1

defines an encapsulation of ICMP (ether2.ip.icmp)

ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."

Bierman/Iddon Expires July 22, 1996 [Page 27]

Draft RMON Protocol Identifiers January 22, 1996

DECODING
"Note: ether2/ip/ipip4/udp is a different protocolDirID than
ether2/ip/udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g.: 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 "
REFERENCE
"RFC 791;
The following URL defines the authoritative repository
for the PROTOCOL NUMBERS Table:

ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x08, 0x06,
snap 0x0800,
ip 4,
ip 94
}

4.2.1.1.

4.3.1.1. Children of IP

Bierman/Iddon Expires May 17, 1996 [Page 25]

Draft RMON Protocol Identifiers November 17, 1995

4.2.1.1.1.

4.3.1.1.1. ICMP

icmp PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"Internet Message Control Protocol."
REFERENCE
"RFC-792"
::= { ip 1 }

4.2.1.1.2.

4.3.1.1.2. TCP

tcp PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of tcp packets that didn't match
-- any children of tcp enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol."
CHILDREN

Bierman/Iddon Expires July 22, 1996 [Page 28]

Draft RMON Protocol Identifiers January 22, 1996

"Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC 793." 793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
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 protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793;
The following URL defines the authoritative repository
for reserved and registered TCP port values:

ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 6 }

4.2.1.1.3.

4.3.1.1.3. UDP

udp PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of udp packets that didn't match
-- any children of udp enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0)
}

Bierman/Iddon Expires May 17, 1996 [Page 26]

Draft RMON Protocol Identifiers November 17, 1995
DESCRIPTION
"User Datagram Protocol."
CHILDREN
"Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC 768." 768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161

identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768;
The following URL defines the authoritative repository
for reserved and registered UDP port values:

ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 17 }

4.2.1.1.3.1.

Bierman/Iddon Expires July 22, 1996 [Page 29]

Draft RMON Protocol Identifiers January 22, 1996

4.3.1.1.3.1. Children of UDP

Note that some of the following protocols can be encapsulated in
protocols other than UDP. The assignment section of each protocol-
identifier macro lists any additional encapsulations.

4.2.1.1.3.1.

4.3.1.1.3.1. SNMP

snmp PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"SNMPv2: RFCs 1441 - 1452;
SNMPv1: RFC 1155,
"Transport Mappings for SNMPv2: RFC 1157; 1449;
SNMP over IPX: RFC 1420;
SNMP over AppleTalk: RFC 1419;"
::= {
udp 161,
ipx 161 0x900f, -- [ 0.0.144.15 ]
atalk 8
}

4.2.1.1.3.1.

4.3.1.1.3.1. SNMPTRAP

snmptrap PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE

Bierman/Iddon Expires May 17, 1996 [Page 27]

Draft RMON Protocol Identifiers November 17, 1995

"SNMPv2: RFCs 1441 - 1452;
"Transport Mappings for SNMPv2: RFC 1449;
SNMPv1: RFC 1155, RFC 1157;
SNMP over IPX: RFC 1420;
SNMP over AppleTalk: RFC 1419;"
::= {
udp 162,
ipx 162 0x9010,
atalk 9
}

4.2.1.1.3.1.

Bierman/Iddon Expires July 22, 1996 [Page 30]

Draft RMON Protocol Identifiers January 22, 1996

4.3.1.1.3.1. TFTP

tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(2)
tracksSessions(1)
}
ATTRIBUTES {}
DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350;
TFTP Option Extension (RFC 1782)
TFTP Blocksize Option (RFC 1783)
TFTP Timeout Interval and Transfer Size Options (RFC 1784)
TFTP Option Negotiation Analysis (RFC 1785)"
::= { udp 69 }

4.2.2.

4.3.2. IPX

ipx PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of ipx packets that didn't match
-- any children of ipx enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the

Bierman/Iddon Expires May 17, 1996 [Page 28]

Draft RMON Protocol Identifiers November 17, 1995
Destination Socket field. The value is encoded into an octet
string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
order encodings of the MSB and LSB of the destination socket
field."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
DECODING
""
REFERENCE
"Novell [TBD]"

Bierman/Iddon Expires July 22, 1996 [Page 31]

Draft RMON Protocol Identifiers January 22, 1996

::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
raw8023 0x8137
wgAssigned ipxOverRaw8023(1) -- 0.0.129.55 0.0.0.1
}

4.2.3.

4.3.3. ARP

arp PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"An 802.3 header followed immediately by a payload (i.e. no TYPE
field)."
An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately.
REFERENCE
"RFC 826"
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}

4.2.4.

4.3.4. IDP

idp PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of idp packets that didn't match
-- any children of idp enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}

Bierman/Iddon Expires May 17, 1996 [Page 29]

Draft RMON Protocol Identifiers November 17, 1995
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
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 in
network byte order.
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"

Bierman/Iddon Expires July 22, 1996 [Page 32]

Draft RMON Protocol Identifiers January 22, 1996

::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}

4.2.5.

4.3.5. Appletalk ARP

atalkarp PROTOCOL-IDENTIFIER
PARAMETERS {}
ATTRIBUTES {}
DESCRIPTION
"Appletalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A."
::= {
ether2 0x80F3, 0x80f3, -- [ 0.0.128.243 ]
snap 0x80F3
vsnap(0x080007) 0x80f3
}

4.2.6.

4.3.6. Appletalk

atalk PROTOCOL-IDENTIFIER
PARAMETERS {
others(1) -- The count of ether2 packets that didn't match
-- any children of ether2 enabled in the protocolDirectory
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."

Bierman/Iddon Expires May 17, 1996 [Page 30]

Draft RMON Protocol Identifiers November 17, 1995
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
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 byte
order.
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order".
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap
vsnap(0x080007) 0x809b
}

Bierman/Iddon Expires May 17, July 22, 1996 [Page 31] 33]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

5. Acknowledgements

This document was produced by the IETF RMONMIB Working Group.

The authors wish to thank the following people for their contributions
to this document:

Anil Singhal
Frontier Software Development, Inc.
anil@frontier.com

Jeanne Haney
Coronet Systems
jeanne@coronet.com
Bay Networks
jhaney@baynetworks.com

Dan Hansen
Network General Corp.
danh@ngc.com

Bierman/Iddon Expires May 17, July 22, 1996 [Page 32] 34]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

6. References

[RFC1212]
Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems,
March 1991.

[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.

[RFC1442]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes
LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.

[RFC1445]
Galvin, J., and K. McCloghrie, "Administrative Model for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April 1993.

[RFC1448]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover
Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.

[RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
Mellon University, February 1995.

[RFC1800]
Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
RFC 1800, IAB, July 1995.

[RMON2]
S. Waldbusser, "Remote Network Monitoring MIB Version 2", draft-

Bierman/Iddon Expires May 17, July 22, 1996 [Page 33] 35]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

ietf-rmonmib-rmon2-02.txt, International Network Services, October
1995.

Bierman/Iddon Expires May 17, July 22, 1996 [Page 34] 36]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

7. Security Considerations

Security issues are not discussed in this memo.

8. Authors' Addresses

Andy Bierman
Bierman Consulting
1200 Sagamore Lane
Ventura, CA 93001
Phone: 805-648-2028
Email: abierman@west.net

Robin Iddon
AXON Networks, Inc.
[TBD]
Phone: [TBD]
Email: robini@axon.com

Bierman/Iddon Expires May 17, July 22, 1996 [Page 35] 37]

Draft RMON Protocol Identifiers November 17, 1995 January 22, 1996

Table of Contents

1 Introduction .................................................... 2
1.1 The SNMPv2 SNMPv1 Network Management Framework ....................... 2
1.1.1 Object Definitions .......................................... 2
2 Overview ........................................................ 3
2.1 Terms ......................................................... 3
2.2 Relationship to the Remote Network Monitoring MIB ............. 5
2.3 Relationship to the Other MIBs ................................ 5
3 Protocol Identifier Encoding .................................... 6
3.1 ProtocolDirTable INDEX Format Examples ........................ 8 9
3.2 Protocol Identifier Macro Format .............................. 9
3.2.1 Mapping of the Protocol Name ................................ 9 10
3.2.2 Mapping of the Protocol Variant Name ........................ 10
3.2.3 Mapping of the PARAMETERS Clause ............................ 10
3.2.2.1 11
3.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 11
3.2.2.2 12
3.2.3.2 Mapping of the 'others(1)' 'tracksSessions(1)' BIT ............................ 12
3.2.2.2.1 Relationship to the protocolDirTable .................... 12
3.2.2.3
3.2.4 Mapping of the 'tracksSessions(2)' BIT .................... VARIANT-OF Clause ............................ 13
3.2.3
3.2.5 Mapping of the ATTRIBUTES Clause ............................ 13
3.2.4
3.2.6 Mapping of the DESCRIPTION Clause ........................... 14
3.2.5
3.2.7 Mapping of the CHILDREN Clause .............................. 14
3.2.6
3.2.8 Mapping of the ADDRESS-FORMAT Clause ........................ 15
3.2.7
3.2.9 Mapping of the DECODING Clause .............................. 15
3.2.8
3.2.10 Mapping of the REFERENCE Clause ............................. ............................ 15
3.2.9
3.2.11 Evaluating a Protocol-Identifier INDEX ...................... ..................... 16
4 Protocol Identifier Macro Examples .............................. Macros ...................................... 17
4.1 Base Identifier Encoding ...................................... 17
4.1.1 Protocol Identifier Functions ............................... 17
4.1.1.1 Normal Encoding: No Functions Selected .................... 18
4.1.1.2 Protocol Wildcard Function ................................ 18
4.2 L2 Protocol Identifiers ....................................... 17
4.1.1 19
4.2.1 Ether2 Encapsulation ........................................ 18
4.1.2 19
4.2.2 LLC Encapsulation ........................................... 19
4.1.3 20
4.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 21
4.1.4 22
4.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 22
4.1.5 Raw 802.3 Encapsulation ..................................... 23
4.2
4.2.5 Working Group Assigned Protocols ............................ 24
4.2.6 Working Group Enumerated Protocol Identifiers ............... 26
4.3 L3 Protocol Identifiers ....................................... 24
4.2.1 26
4.3.1 IP .......................................................... 24
4.2.1.1 27
4.3.1.1 Children of IP ............................................ 25
4.2.1.1.1 28
4.3.1.1.1 ICMP .................................................... 26
4.2.1.1.2 28
4.3.1.1.2 TCP ..................................................... 26
4.2.1.1.3 28
4.3.1.1.3 UDP ..................................................... 26
4.2.1.1.3.1 29
4.3.1.1.3.1 Children of UDP ....................................... 27
4.2.1.1.3.1 30

Bierman/Iddon Expires July 22, 1996 [Page 38]

Draft RMON Protocol Identifiers January 22, 1996

4.3.1.1.3.1 SNMP .................................................. 27
4.2.1.1.3.1 30
4.3.1.1.3.1 SNMPTRAP .............................................. 27
4.2.1.1.3.1 30
4.3.1.1.3.1 TFTP .................................................. 28
4.2.2 31
4.3.2 IPX ......................................................... 28
4.2.3 31
4.3.3 ARP ......................................................... 29

Bierman/Iddon Expires May 17, 1996 [Page 36]

Draft RMON Protocol Identifiers November 17, 1995

4.2.4 32
4.3.4 IDP ......................................................... 29
4.2.5 32
4.3.5 Appletalk ARP ............................................... 30
4.2.6 33
4.3.6 Appletalk ................................................... 30 33
5 Acknowledgements ................................................ 32 34
6 References ...................................................... 33 35
7 Security Considerations ......................................... 35 37
8 Authors' Addresses .............................................. 35 37

Bierman/Iddon Expires May 17, July 22, 1996 [Page 37] 39]

----