< draft-ietf-rmonmib-rmonprot-01.txt   draft-ietf-rmonmib-rmonprot-02.txt >
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
Remote Network Monitoring MIB Protocol Identifiers Remote Network Monitoring MIB Protocol Identifiers
<draft-ietf-rmonmib-rmonprot-01.txt> <draft-ietf-rmonmib-rmonprot-02.txt>
22 January 1996 22 May 1996
Andy Bierman Andy Bierman
Bierman Consulting Cisco Systems Inc.
abierman@west.net abierman@cisco.com
Robin Iddon Robin Iddon
AXON Networks, Inc. AXON Networks, Inc.
robini@axon.com robini@axon.com
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
1. Introduction 1. Introduction
This memo defines an experimental portion of the Management Information This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes the algorithms required to community. In particular, it describes the algorithms required to
identify different protocol encapsulations managed with the Remote identify different protocol encapsulations managed with the Remote
Network Monitoring MIB Version 2 (RMON-2) [RMON2]. Although related to Network Monitoring MIB Version 2 [RMON2]. Although related to the
the original Remote Network Monitoring MIB (RMON) [RFC1757], this original Remote Network Monitoring MIB [RFC1757], this document refers
document refers only to objects found in the RMON-2 MIB. only to objects found in the RMON-2 MIB.
1.1. The SNMPv1 Network Management Framework Draft RMON Protocol Identifiers May 1996
The SNMPv1 Network Management Framework presently consists of two major 2. The SNMP Network Management Framework
The SNMP Network Management Framework presently consists of three major
components. They are: components. They are:
o RFC 1442 [RFC1442] which defines the SMI, the mechanisms used for o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
describing and naming objects for the purpose of management. describing and naming objects for the purpose of management.
o STD 17, RFC 1213 [RFC1213] defines MIB-II, the core set of managed o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
objects for the Internet suite of protocols. objects for the Internet suite of protocols.
o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the
protocol for accessing managed information.
Textual conventions are defined in RFC 1903 [RFC1903], and conformance
statements are defined in RFC 1904 [RFC1904].
The Framework permits new objects to be defined for the purpose of The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. experimentation and evaluation.
1.1.1. Object Definitions 2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined Management Information Base or MIB. Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the 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, SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
an administratively assigned name. The object type together with an an administratively assigned name. The object type together with an
object instance serves to uniquely identify a specific instantiation of object instance serves to uniquely identify a specific instantiation of
the object. For human convenience, we often use a textual string, the object. For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type. termed the descriptor, to refer to the object type.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
2. Overview 3. Overview
The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to
globally identify individual protocol encapsulations in the globally identify individual protocol encapsulations in the
protocolDirTable. protocolDirTable.
This guide contains algorithms and examples of protocol identifier This guide contains algorithms and examples of protocol identifier
encapsulations for use as INDEX values in the protocolDirTable. encapsulations for use as INDEX values in the protocolDirTable.
This document is not intended to be an authoritative reference on the This document is not intended to be an authoritative reference on the
protocols described herein. Refer to the Official Internet Standards protocols described herein. Refer to the Official Internet Standards
document (RFC 1800) [RFC1800], the Assigned Numbers document (RFC 1700) document [RFC1800], the Assigned Numbers document [RFC1700], or other
[RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete appropriate RFCs, IEEE documents, etc. for complete and authoritative
and authoritative protocol information. protocol information.
2.1. Terms 3.1. Terms
Several terms are used throughout this document, as well as in the Several terms are used throughout this document, as well as in the
RMON-2 MIB [RMON2], that should be introduced: RMON-2 MIB [RMON2], that should be introduced:
layer-identifier: layer-identifier:
An octet string fragment representing a particular protocol An octet string fragment representing a particular protocol
encapsulation layer. A four-octet string fragment identifying a encapsulation layer. A string fragment identifying a particular
particular protocol encapsulation layer. This string is exactly protocol encapsulation layer. This string is exactly four octets,
four octets, (except for the 'vsnap' pseudo-MAC-layer identifier, (except for the 'vsnap' base-layer identifier, which is exactly
which is exactly eight octets) encoded in network byte order. A eight octets) encoded in network byte order. A particular protocol
particular protocol encapsulation can be identified by starting encapsulation can be identified by starting with a base layer
with a MAC layer encapsulation (see the 'L2 Protocol Identifiers' encapsulation (see the 'Base Protocol Identifiers' section for more
section for more detail), and following the encoding rules detail), and following the encoding rules specified in the CHILDREN
specified in the CHILDREN clause and assignment section for that clause and assignment section for that layer. Then repeat for each
layer. Then repeat for each identified layer in the encapsulation. identified layer in the encapsulation. (See section 4.2.10
(See the section 'Evaluating a Protocol-Identifier INDEX' for more 'Evaluating a Protocol-Identifier INDEX' for more detail.)
detail.)
protocol: protocol:
A particular protocol layer, as specified by encoding rules in this A particular protocol layer, as specified by encoding rules in this
document. Usually refers to a single layer in a given document. Usually refers to a single layer in a given
encapsulation. Note that this term is sometimes used in the RMON-2 encapsulation. Note that this term is sometimes used in the RMON-2
MIB [RMON2] to name a fully-specified protocol-identifier string. MIB [RMON2] to name a fully-specified protocol-identifier string.
In such a case, the protocol-identifier string is named for its In such a case, the protocol-identifier string is named for its
upper-most layer. A named protocol may also refer to any upper-most layer. A named protocol may also refer to any
encapsulation of that protocol. encapsulation of that protocol.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
protocol-identifier string: protocol-identifier string:
An octet string representing a particular protocol encapsulation, An octet string representing a particular protocol encapsulation,
as specified by encoding rules in this document. This string is as specified by encoding rules in this document. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
protocol-identifier string is composed of one or more layer- protocol-identifier string is composed of one or more layer-
identifiers. identifiers.
protocol-identifier macro: protocol-identifier macro:
A group of formatted text describing a particular protocol layer, A group of formatted text describing a particular protocol layer,
skipping to change at page 4, line 34 skipping to change at page 5, line 34
- Describe how the associated protocolDirType object is encoded - Describe how the associated protocolDirType object is encoded
for the protocol. for the protocol.
- Provide reference(s) to authoritative documentation for the - Provide reference(s) to authoritative documentation for the
protocol. protocol.
protocol-variant-identifier macro: protocol-variant-identifier macro:
A group of formatted text describing a particular protocol layer, A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. This protocol is a variant as used within the RMON-2 MIB [RMON2]. This protocol is a variant
of a well known encapsulation that may be present in the of a well known encapsulation that may be present in the
protocolDirTable. This macro is used to document the working group protocolDirTable. This macro is used to document the working group
assigned protocols. All other protocols should be documented using assigned protocols, which are needed to identify protocols which
the protocol-identifier macro. cannot be practically identified by examination of 'appropriate
network traffic' (e.g. the packets which carry them). All other
protocols (which can be identified by examination of appropriate
network traffic) should be documented using the protocol-identifier
macro. A protocol-variant-identifier is documented using the
protocol-variant version of the protocol-identifier macro.
protocol-parameter: protocol-parameter:
A single octet, corresponding to a specific layer-identifier in the A single octet, corresponding to a specific layer-identifier in the
protocol-identifier. This octet is a bit-mask indicating special protocol-identifier. This octet is a bit-mask indicating special
functions or capabilities that this agent is providing for the functions or capabilities that this agent is providing for the
corresponding protocol. corresponding protocol.
protocol-parameters string: protocol-parameters string:
An octet string, which contains one protocol-parameter for each An octet string, which contains one protocol-parameter for each
layer-identifier in the protocol-identifier. See the section layer-identifier in the protocol-identifier. See the section
'Mapping of the PARAMETERS Clause' for more detail. This string is 'Mapping of the PARAMETERS Clause' for more detail. This string is
Draft RMON Protocol Identifiers May 1996
identified in the RMON-2 MIB [RMON2] as the protocolDirParameters identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
object. object.
protocolDirTable INDEX: protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair A protocol-identifier and protocol-parameters octet string pair
Draft RMON Protocol Identifiers January 22, 1996
that have been converted to an INDEX value, according to the that have been converted to an INDEX value, according to the
encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212]. encoding rules in in section 7.7 of RFC 1902 [RFC1902].
pseudo-protocol: pseudo-protocol:
A convention or algorithm used only within this document for the A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings. purpose of encoding protocol-identifier strings.
2.2. Relationship to the Remote Network Monitoring MIB 3.2. Relationship to the Remote Network Monitoring MIB
This document is intended to identify possible string values for the This document is intended to identify possible string values for the
OCTET STRING objects protocolDirID and protocolDirParameters. Tables in OCTET STRING objects protocolDirID and protocolDirParameters. Tables in
the new Protocol Distribution, Host, and Matrix groups use a local the new Protocol Distribution, Host, and Matrix groups use a local
INTEGER INDEX, in order to remain unaffected by changes in this INTEGER INDEX, in order to remain unaffected by changes in this
document. Only the protocolDirTable uses the strings (protocolDirID and document. Only the protocolDirTable uses the strings (protocolDirID and
protocolDirParameters) described in this document. protocolDirParameters) described in this document.
This document is not intended to limit the protocols that may be This document is not intended to limit the protocols that may be
identified for counting in the RMON-2 MIB. Many protocol encapsulations, identified for counting in the RMON-2 MIB. Many protocol encapsulations,
not explicitly identified in this document, may be present in an actual not explicitly identified in this document, may be present in an actual
implementation of the protocolDirTable. Also, implementations of the implementation of the protocolDirTable. Also, implementations of the
protocolDirTable may not include all the protocols identified in the protocolDirTable may not include all the protocols identified in the
example section below. example section below.
This document is intentionally separated from the MIB objects to allow
frequent updates to this document without any republication of MIB
objects. Protocol Identifier macros submitted from the RMON working
group and community at large (to the RMONMIB WG mailing list at
'rmonmib@cisco.com') will be collected and added to this document,
approximately three times a year. Macros submissions will be collected
in the RMONMIB WG archive under the directory
"ftp://ftp.cisco.com/ftp/rmonmib/rmon2_pi_macros/" or in the mailing
list message archive file "ftp://ftp.cisco.com/ftp/rmonmib/rmonmib".
This document does not discuss auto-discovery and auto-population of the This document does not discuss auto-discovery and auto-population of the
protocolDirTable. This functionality is not explicitly defined by the protocolDirTable. This functionality is not explicitly defined by the
RMON standard. An agent should populate the directory with 'interesting' RMON standard. An agent should populate the directory with 'interesting'
protocols--depending on the intended applications. protocols--depending on the intended applications.
2.3. Relationship to the Other MIBs Draft RMON Protocol Identifiers May 1996
3.3. Relationship to the Other MIBs
The RMON Protocol Identifiers document is intended for use with the The RMON Protocol Identifiers document is intended for use with the
protocolDirTable within the RMON MIB. It is not relevant to any other protocolDirTable within the RMON MIB. It is not relevant to any other
MIB, or intended for use with any other MIB. MIB, or intended for use with any other MIB.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
3. Protocol Identifier Encoding 4. Protocol Identifier Encoding
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and
protocolDirParameters. To encode the table index, each variable-length protocolDirParameters. To encode the table index, each variable-length
string is converted to an OBJECT IDENTIFIER fragment, according to the 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 encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index
index fragments are simply concatenated. (Refer to figures 1a - 1d below fragments are simply concatenated. (Refer to figures 1a - 1d below for
for more detail.) more detail.)
The first OCTET STRING (protocolDirID) is composed of one or more 4- The first OCTET STRING (protocolDirID) is composed of one or more 4-
octet "layer-identifiers". The entire string uniquely identifies a octet "layer-identifiers". The entire string uniquely identifies a
particular protocol encapsulation tree. The second OCTET STRING, particular protocol encapsulation tree. The second OCTET STRING,
(protocolDirParameters) which contains a corresponding number of 1-octet (protocolDirParameters) which contains a corresponding number of 1-octet
protocol-specific parameters, one for each 4-octet layer-identifier in protocol-specific parameters, one for each 4-octet layer-identifier in
the first string. the first string.
A protocol layer is normally identified by a single 32-bit value. Each A protocol layer is normally identified by a single 32-bit value. Each
layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as 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 four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of
the 32-bit value in network byte order. If a particular protocol layer the 32-bit value in network byte order. If a particular protocol layer
cannot be encoded into 32 bits, (except for the 'vsnap' MAC layer) then cannot be encoded into 32 bits, (except for the 'vsnap' base layer) then
it must be defined as a 'wgAssigned' protocol (see below for details on it must be defined as a 'wgAssigned' protocol (see below for details on
working group assigned protocols). working group assigned protocols).
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
The following figures show the differences between the OBJECT IDENTIFIER The following figures show the differences between the OBJECT IDENTIFIER
and OCTET STRING encoding of the protocol identifier string. and OCTET STRING encoding of the protocol identifier string.
Fig. 1a Fig. 1a
protocolDirTable INDEX Format protocolDirTable INDEX Format
----------------------------- -----------------------------
+---+--------------------------+---+---------------+ +---+--------------------------+---+---------------+
| c ! | c ! protocolDir | | c ! | c ! protocolDir |
skipping to change at page 7, line 45 skipping to change at page 9, line 45
| | | |
+----------+ +----------+
Fig. 1c Fig. 1c
protocolDirTable INDEX Format Example protocolDirTable INDEX Format Example
------------------------------------- -------------------------------------
protocolDirID protocolDirParameters protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+ +---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par| | c | proto | proto | proto | proto | c |par|par|par|par|
| n | L2 | L3 | L4 | L5 | n | L2| L3| L4| L5| | n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t | | | | | | t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID +---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count | 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that for the entire encapsulation of the named protocol. Note that
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
the 'vsnap' MAC layer identifier is encoded into 8 sub-identifiers, the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
All other protocol layers are either encoded into 4 sub-identifiers All other protocol layers are either encoded into 4 sub-identifiers
or encoded as a 'wgAssigned' protocol. or encoded as a 'wgAssigned' protocol.
Fig. 1d Fig. 1d
protocolDirTable OCTET STRING Format Example protocolDirTable OCTET STRING Format Example
-------------------------------------------- --------------------------------------------
protocolDirID protocolDirID
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| proto | proto | proto | proto | | proto | proto | proto | proto |
| L2 | L3 | L4 | L5 | | base | L3 | L4 | L5 |
| | | | | | | | | |
+--------+--------+--------+--------+ octet +--------+--------+--------+--------+ octet
| 4 or 8 | 4 | 4 | 4 | count | 4 or 8 | 4 | 4 | 4 | count
protocolDirParameters protocolDirParameters
+---+---+---+---+ +---+---+---+---+
|par|par|par|par| |par|par|par|par|
| L2| L3| L4| L5| |ba-| L3| L4| L5|
| | | | | |se | | | |
+---+---+---+---+ octet +---+---+---+---+ octet
|1/2| 1 | 1 | 1 | count |1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that for the entire encapsulation of the named protocol. Note that
the 'vsnap' MAC layer identifier is encoded into 8 the 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters protocolDirID sub-identifiers and 2 protocolDirParameters
sub-identifiers. sub-identifiers.
Although this example indicates four encapsulated protocols, in Although this example indicates four encapsulated protocols, in
practice, any non-zero number of layer-identifiers may be present, practice, any non-zero number of layer-identifiers may be present,
theoretically limited only by OBJECT IDENTIFIER length restrictions, as theoretically limited only by OBJECT IDENTIFIER length restrictions, as
specified in section 7.1.3 of RFC 1442 [RFC1442]. specified in section 3.5 of RFC 1902 [RFC1902].
Note that these two strings would not be concatenated together if ever Note that these two strings would not be concatenated together if ever
returned in a GetResponse PDU, since they are different MIB objects. returned in a GetResponse PDU, since they are different MIB objects.
However, protocolDirID and protocolDirParameters are not currently However, protocolDirID and protocolDirParameters are not currently
readable MIB objects. readable MIB objects.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
3.1. ProtocolDirTable INDEX Format Examples 4.1. ProtocolDirTable INDEX Format Examples
-- HTTP; fragments counted from IP and above -- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http = 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 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 -- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp = 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 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over SNAP -- SNMP over IPX over SNAP
skipping to change at page 9, line 45 skipping to change at page 11, line 45
8.2.1.0.1.0.0.8.0.2.0.0 8.2.1.0.1.0.0.8.0.2.0.0
-- Appletalk Phase 2 over ether2 -- Appletalk Phase 2 over ether2
-- ether2.atalk -- ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0 8.0.0.0.1.0.0.128.155.2.0.0
-- Appletalk Phase 2 over vsnap -- Appletalk Phase 2 over vsnap
-- vsnap(apple).atalk -- vsnap(apple).atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
3.2. Protocol Identifier Macro Format 4.2. Protocol Identifier Macro Format
The following example is meant to introduce the protocol-identifier and The following example is meant to introduce the protocol-identifier
protocol-variant-identifier macros. The syntax is not ASN.1; The macro. (The syntax is not quite ASN.1.) This macro is used to represent
definitive BNF definitions for the protocol-identifier macro syntax can both protocols and protocol-variants.
be found in Appendix A [TBD].
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
A protocol-variant-identifier is used only for working group assigned If the 'VariantOfPart' component of the macro is present, then the macro
protocols, enumerated under the 'wgAssigned' pseudo-MAC-layer tree. represents a protocol-variant instead of a protocol. A protocol-
variant-identifier is used only for working group assigned protocols,
enumerated under the 'wgAssigned' base-layer.
protocol-identifier :== RMON-PROTOCOL-IDENTIFIER MACRO ::=
<protocol-name> "PROTOCOL-IDENTIFIER" BEGIN
"PARAMETERS" "{" <param-bit-list> "}" PIMacroName "PROTOCOL-IDENTIFIER"
"ATTRIBUTES" "{" <attrib-bit-list> "}" VariantOfPart
"DESCRIPTION" """ <protocol-description> """ "PARAMETERS" ParamPart
[ "CHILDREN" """ <children-description> """ ] "ATTRIBUTES" AttrPart
[ "ADDRESS-FORMAT" """ <address-format-description> """ ] "DESCRIPTION" Text
[ "DECODING" """ <decoding-description> """ ] ChildDescrPart
[ "REFERENCE" """ <reference-description> """ ] AddrDescrPart
"::=" "{" <protocol-encoding-identifiers> "}" DecodeDescrPart
ReferPart
"::=" "{" EncapsPart "}"
protocol-variant-identifier :== PIMacroName ::=
<protocol-variant-name> "PROTOCOL-VARIANT-IDENTIFIER" 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 VariantOfPart ::=
"VARIANT-OF" identifier | empty
The 'protocol-name' value must be an lower-case ASCII string, and if ParamPart ::=
possible, should match the "most well-known" name or acronym for the "{" ParamList "}"
indicated protocol. For example, the document indicated by the URL:
ParamList ::=
Params | empty
Params ::=
Param | Params "," Param
Param ::=
identifier "(" nonNegativeNumber ")"
AttrPart ::=
"{" AttrList "}"
AttrList ::=
Attrs | empty
Attrs ::=
Attr | Attrs "," Attr
Draft RMON Protocol Identifiers May 1996
Attr ::=
identifier "(" nonNegativeNumber ")"
ChildDescrPart ::=
"CHILDREN" Text | empty
AddrDescrPart ::=
"ADDRESS-FORMAT" Text | empty
DecodeDescrPart ::=
"DECODING" Text | empty
ReferPart ::=
"REFERENCE" Text | empty
EncapsPart ::=
"{" Encaps "}"
Encaps ::=
Encap | Encaps "," Encap
Encap ::=
BaseEncap | NormalEncap | VsnapEncap | WgEncap
BaseEncap ::=
nonNegativeNumber
NormalEncap ::=
identifier nonNegitiveNumber
VsnapEncap ::=
identifier "(" nonNegativeNumber ")" nonNegativeNumber
WgEncap ::=
"wgAssigned" nonNegativeNumber
| "wgAssigned" identifier
| "wgAssigned" identifier "(" nonNegativeNumber ")"
Text ::=
"""" string """"
END
Draft RMON Protocol Identifiers May 1996
4.2.1. Mapping of the Protocol Name
The 'PIMacroName' value should be a lower-case ASCII string, and contain
the name or acronym identifying the protocol. NMS applications may
treat protocol names as case-insensitive strings, and agent
implementations must make sure the protocolDirTable does not contain any
instances of the protocolDirDescr object which differ only in the case
of one of more letters (if the identifiers are intended to represent
different protocols).
It is possible that different encapsulations of the same protocol (which
are represented by different entries in the protocolDirTable) will be
assigned the same protocol name.
A protocol name should match the "most well-known" name or acronym for
the indicated protocol. For example, the document indicated by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for defines IP Protocol field values, so protocol-identifier macros for
children of IP should be given names consistent with the protocol names children of IP should be given names consistent with the protocol names
found in this authoritative document. found in this authoritative document.
3.2.2. Mapping of the Protocol Variant Name 4.2.2. Mapping of the VARIANT-OF Clause
The 'protocol-variant-name' value must be an lower-case ASCII string, This clause is present for working group assigned protocols only. It
and must match the working group assigned name for that protocol. For identifies the protocol-identifier macro that most closely represents
Draft RMON Protocol Identifiers January 22, 1996 this particular protocol, and is known as the "reference protocol". (A
protocol-identifier macro must exist for the reference protocol.) When
this clause is present in a protocol-identifier macro, the macro is
called a 'protocol-variant-identifier'.
'wgAssigned' protocols, the enumeration identifier should be used as the Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-
protocol-variant-name for the indicated protocol. identifier macro should not be duplicated in the protocol-variant-
identifier macro, if the 'variant' protocols' semantics are identical
for a given clause.
3.2.3. Mapping of the PARAMETERS Clause Since the PARAMETERS and ATTRIBUTES clauses must be present in a
protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
"PARAMETERS {}") must be present in a protocol-variant-identifier macro,
and the 'ParamPart' and 'AttrPart' found in the reference protocol-
identifier macro examined instead.
Draft RMON Protocol Identifiers May 1996
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 version of the macro.
4.2.3. Mapping of the PARAMETERS Clause
The protocolDirParameters object provides an NMS the ability to turn on The protocolDirParameters object provides an NMS the ability to turn on
and off expensive probe resources. An agent may support a given and off expensive probe resources. An agent may support a given
parameter all the time, not at all, or subject to current resource load. 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 The PARAMETERS clause is a list of bit definitions which can be directly
encoded into the associated ProtocolDirParameters octet in network byte encoded into the associated ProtocolDirParameters octet in network byte
order. Zero or more bit definitions may be present. Only bits 0-7 are 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 valid encoding values. This clause defines the entire BIT set allowed
for a given protocol. A conformant agent may choose to implement a for a given protocol. A conforming agent may choose to implement a
subset of zero or more of these PARAMETERS. subset of zero or more of these PARAMETERS.
By convention, the following common bit definitions are used by By convention, the following common bit definitions are used by
different protocols. These bit positions must not be used for other different protocols. These bit positions must not be used for other
parameters. They should be reserved if not used by a given protocol. parameters. They should be reserved if not used by a given protocol.
Bits are encoded in network-byte order.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
Table 3.1 Reserved PARAMETERS Bits Table 3.1 Reserved PARAMETERS Bits
------------------------------------ ------------------------------------
Bit Name Description Bit Name Description
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within 0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even this protocol will be counted correctly even
if this protocol fragments the upper layers if this protocol fragments the upper layers
into multiple packets. into multiple packets.
skipping to change at page 12, line 27 skipping to change at page 16, line 27
which starts sessions on well known ports or which starts sessions on well known ports or
sockets and then transfers them to dynamically sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP). assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause must be present in all protocol-identifier macro The PARAMETERS clause must be present in all protocol-identifier macro
declarations, but may be equal to zero (empty). Note that an NMS must declarations, but may be equal to zero (empty). Note that an NMS must
determine if a given PARAMETER bit is supported by attempting to create determine if a given PARAMETER bit is supported by attempting to create
the desired protocolDirEntry The associated ATTRIBUTE bits for the desired protocolDirEntry The associated ATTRIBUTE bits for
'countsFragments' and 'tracksSessions' do not exist. 'countsFragments' and 'tracksSessions' do not exist.
3.2.3.1. Mapping of the 'countsFragments(0)' BIT 4.2.3.1. Mapping of the 'countsFragments(0)' BIT
This bit indicates whether the probe is correctly attributing all This bit indicates whether the probe is correctly attributing all
fragmented packets of the specified protocol, even if individual frames fragmented packets of the specified protocol, even if individual frames
carrying this protocol cannot be identified as such. Note that the carrying this protocol cannot be identified as such. Note that the
probe is not required to actually present any re-assembled datagrams probe is not required to actually present any re-assembled datagrams
(for address-analysis, filtering, or any other purpose) to the NMS. (for address-analysis, filtering, or any other purpose) to the NMS.
This bit may only be set in a protocolDirParameters octet which This bit may only be set in a protocolDirParameters octet which
corresponds to a protocol that supports fragmentation and reassembly in corresponds to a protocol that supports fragmentation and reassembly in
some form. Note that TCP packets are not considered 'fragmented-streams' some form. Note that TCP packets are not considered 'fragmented-streams'
and so TCP is not eligible. and so TCP is not eligible.
This bit may be set in at most one protocolDirParameters octet within a This bit may be set in at most one protocolDirParameters octet within a
protocolDirTable INDEX. protocolDirTable INDEX.
3.2.3.2. Mapping of the 'tracksSessions(1)' BIT 4.2.3.2. Mapping of the 'tracksSessions(1)' BIT
The 'tracksSessions(1)' bit indicates whether frames which are part of The 'tracksSessions(1)' bit indicates whether frames which are part of
remapped-sessions (e.g. TFTP download sessions) are correctly counted by remapped-sessions (e.g. TFTP download sessions) are correctly counted by
the probe. For such a protocol, the probe must usually analyze all the probe. For such a protocol, the probe must usually analyze all
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
packets received on the indicated interface, and maintain some state packets received on the indicated interface, and maintain some state
information, (e.g. the remapped UDP port number for TFTP). information, (e.g. the remapped UDP port number for TFTP).
The semantics of the 'tracksSessions' parameter are independent of the The semantics of the 'tracksSessions' parameter are independent of the
other protocolDirParameters definitions, so this parameter may be other protocolDirParameters definitions, so this parameter may be
combined with any other legal parameter configurations. combined with any other legal parameter configurations.
3.2.4. Mapping of the VARIANT-OF Clause 4.2.4. Mapping of the ATTRIBUTES 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 The protocolDirType object provides an NMS with an indication of a
probe's capabilities for decoding a given protocol, or the general probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol. attributes of the particular protocol.
The ATTRIBUTES clause is a list of bit definitions which are encoded The ATTRIBUTES clause is a list of bit definitions which are encoded
into the associated instance of ProtocolDirType. The BIT definitions are into the associated instance of ProtocolDirType. The BIT definitions are
specified in the SYNTAX clause of the protocolDirType MIB object. specified in the SYNTAX clause of the protocolDirType MIB object.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
Table 3.2 Reserved ATTRIBUTES Bits Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------ ------------------------------------
Bit Name Description Bit Name Description
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 hasChildren indicates that there may be children of 0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable this protocol defined in the protocolDirTable
(by either the agent or the manager). (by either the agent or the manager).
1 addressRecognitionCapable 1 addressRecognitionCapable
indicates that this protocol can be used indicates that this protocol can be used
to generate host and matrix table entries. to generate host and matrix table entries.
The ATTRIBUTES clause must be present in all protocol-identifier macro The ATTRIBUTES clause must be present in all protocol-identifier macro
declarations, but may be empty. declarations, but may be empty.
3.2.6. Mapping of the DESCRIPTION Clause 4.2.5. Mapping of the DESCRIPTION Clause
The DESCRIPTION clause provides a textual description of the protocol The DESCRIPTION clause provides a textual description of the protocol
identified by this macro. Notice that it should not contain details identified by this macro. Notice that it should not contain details
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
REFERENCE clauses. REFERENCE clauses.
The DESCRIPTION clause must be present in all protocol-identifier macro The DESCRIPTION clause must be present in all protocol-identifier macro
declarations. declarations.
3.2.7. Mapping of the CHILDREN Clause 4.2.6. Mapping of the CHILDREN Clause
The CHILDREN clause provides a description of child protocols for The CHILDREN clause provides a description of child protocols for
protocols which support them. It has three sub-sections: protocols which support them. It has three sub-sections:
- Details on the field(s)/value(s) used to select the child protocol, - Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed and how that selection process is performed
- Details on how the value(s) are encoded in the protocol identifier - Details on how the value(s) are encoded in the protocol identifier
octet string octet string
- Details on how child protocols are named with respect to their - Details on how child protocols are named with respect to their
parent protocol label(s) parent protocol label(s)
The CHILDREN clause must be present in all protocol-identifier macro The CHILDREN clause must be present in all protocol-identifier macro
declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES
clause. clause.
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
3.2.8. Mapping of the ADDRESS-FORMAT Clause 4.2.7. Mapping of the ADDRESS-FORMAT Clause
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
format(s) used when encoding addresses. format(s) used when encoding addresses.
This clause must be present in all protocol-identifier macro This clause must be present in all protocol-identifier macro
declarations in which the 'addressRecognitionCapable(1)' BIT is set in declarations in which the 'addressRecognitionCapable(1)' BIT is set in
the ATTRIBUTES clause. the ATTRIBUTES clause.
3.2.9. Mapping of the DECODING Clause 4.2.8. Mapping of the DECODING Clause
The DECODING clause provides a description of the decoding procedure for The DECODING clause provides a description of the decoding procedure for
the specified protocol. It contains useful decoding hints for the the specified protocol. It contains useful decoding hints for the
implementor, but should not over-replicate information in documents implementor, but should not over-replicate information in documents
cited in the REFERENCE clause. It might contain a complete description cited in the REFERENCE clause. It might contain a complete description
of any decoding information required. of any decoding information required.
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection as offset and type information for the field(s) used for child selection as
well as information on determining the start of the child protocol. well as information on determining the start of the child protocol.
For 'addressRecognitionCapable' protocols this includes offset and type For 'addressRecognitionCapable' protocols this includes offset and type
information for the field(s) used to generate addresses. information for the field(s) used to generate addresses.
The DECODING clause is optional, and may be omitted if the REFERENCE The DECODING clause is optional, and may be omitted if the REFERENCE
clause contains pointers to decoding information for the specified clause contains pointers to decoding information for the specified
protocol. protocol.
3.2.10. Mapping of the REFERENCE Clause 4.2.9. Mapping of the REFERENCE Clause
If a publicly available reference document exists for this protocol it 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 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. then it will be the name and address of the controlling body.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
amount of information which may currently be obtained from an amount of information which may currently be obtained from an
'authoritative' document, such as the Assigned Numbers document (RFC 'authoritative' document, such as the Assigned Numbers document
1700) [RFC1700]. Any duplication or paraphrasing of information should [RFC1700]. Any duplication or paraphrasing of information should be
be brief and consistent with the authoritative document. brief and consistent with the authoritative document.
The REFERENCE clause is optional, but should be implemented if an The REFERENCE clause is optional, but should be implemented if an
authoritative reference exists for the protocol (especially for standard authoritative reference exists for the protocol (especially for standard
protocols). protocols).
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
3.2.11. Evaluating a Protocol-Identifier INDEX 4.2.10. Evaluating a Protocol-Identifier INDEX
The following evaluation is done after protocolDirTable INDEX value has The following evaluation is done after protocolDirTable INDEX value has
been converted into two OCTET STRINGs according to the INDEX encoding been converted into two OCTET STRINGs according to the INDEX encoding
rules specified in RFC 1212. rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the Protocol-identifiers are evaluated left to right, starting with the
protocolDirID, which length should be evenly divisible by four. The protocolDirID, which length should be evenly divisible by four. The
protocolDirParameters length should be exactly one quarter of the protocolDirParameters length should be exactly one quarter of the
protocolDirID string length. protocolDirID string length.
Protocol-identifier parsing starts with the MAC layer identifier, which Protocol-identifier parsing starts with the base layer identifier, which
must be present, and continues for one or more upper layer identifiers, 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 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 skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can
not exist. not exist.
The MAC-layer-identifier also contains a 'special function identifier' The base-layer-identifier also contains a 'special function identifier'
which may apply to the rest of the protocol identifier. which may apply to the rest of the protocol identifier.
Wild-carding at th MAC layer within a protocol encapsulation is the only Wild-carding at the base layer within a protocol encapsulation is the
supported special function at this time. Refer to the 'L2 Protocol only supported special function at this time. Refer to the 'Base
Identifiers' section for wildcard encoding rules. Protocol Identifiers' section for wildcard encoding rules.
After the protocol-tree identified in protocolDirID has been parsed, After the protocol-tree identified in protocolDirID has been parsed,
each parameter bit-mask (one octet for each 4-octet layer-identifier) is each parameter bit-mask (one octet for each 4-octet layer-identifier) is
evaluated, and applied to the corresponding protocol layer. evaluated, and applied to the corresponding protocol layer.
A protocol-identifier label may map to more than one value. For A protocol-identifier label may map to more than one value. For
instance, 'ip' maps to 5 distinct values, one for each supported instance, 'ip' maps to 5 distinct values, one for each supported
encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'), encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'),
It is important to note that these macros are conceptually expanded at It is important to note that these macros are conceptually expanded at
implementation time, not at run time. implementation time, not at run time.
If all the macros are expanded completely by substituting all possible If all the macros are expanded completely by substituting all possible
values of each label for each child protocol, a list of all possible values of each label for each child protocol, a list of all possible
protocol-identifiers is produced. So 'ip' would result in 5 distinct protocol-identifiers is produced. So 'ip' would result in 5 distinct
protocol-identifiers. Likewise each child of 'ip' would map to at least protocol-identifiers. Likewise each child of 'ip' would map to at least
5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2,
ip over LLC, etc.). ip over LLC, etc.).
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
4. Protocol Identifier Macros 5. Protocol Identifier Macros
The following PROTOCOL IDENTIFIER macros can be used to construct The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParameters strings. protocolDirID and protocolDirParameters strings.
The sections defining protocol examples are intended to grow over The sections defining protocol examples are intended to grow over
subsequent releases. Minimal protocol support is included at this time. subsequent releases. Minimal protocol support is included at this time.
(Refer to section 3.2 for details on the protocol macro update
procedure.)
An identifier is encoded by constructing the base-identifier, then An identifier is encoded by constructing the base-identifier, then
adding one layer-identifier for each encapsulated protocol. adding one layer-identifier for each encapsulated protocol.
4.1. Base Identifier Encoding 5.1. Base Identifier Encoding
The first layer encapsulation is called the base identifier and it The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the MAC layer contains optional protocol-function information and the base layer (e.g.
enumeration value used in this protocol identifier. MAC layer) enumeration value used in this protocol identifier.
The base identifier is encoded as four octets as shown in figure 2. The base identifier is encoded as four octets as shown in figure 2.
Fig. 2 Fig. 2
base-identifier format base-identifier format
+---+---+---+---+ +---+---+---+---+
| | | | | | | | | |
| f |op1|op2| m | | f |op1|op2| m |
| | | | | | | | | |
+---+---+---+---+ octet +---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count | 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table 4.1. 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 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, 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, 'm', is the enumerated value for a particular base layer encapsulation,
found in table 4.2. All four octets are encoded in network-byte-order. found in table 4.2. All four octets are encoded in network-byte-order.
4.1.1. Protocol Identifier Functions 5.1.1. Protocol Identifier Functions
The base layer identifier contains information about any special The base layer identifier contains information about any special
functions to perform during collections of this protocol, as well as the functions to perform during collections of this protocol, as well as the
MAC layer encapsulation identifier. base layer encapsulation identifier.
The first three octets of the identifier contain the function code and Draft RMON Protocol Identifiers May 1996
two optional operands. The fourth octet contains the particular MAC
Draft RMON Protocol Identifiers January 22, 1996
The first three octets of the identifier contain the function code and
two optional operands. The fourth octet contains the particular base
layer encapsulation used in this protocol (fig. 2). layer encapsulation used in this protocol (fig. 2).
By design, only 255 different MAC layer encapsulations are supported.
There are five encapsulation values defined at this time.
Table 4.1 Assigned Protocol Identifier Functions Table 4.1 Assigned Protocol Identifier Functions
------------------------------------------------- -------------------------------------------------
Function ID Param1 Param2 Function ID Param1 Param2
---------------------------------------------------- ----------------------------------------------------
none 0 not used (0) not used (0) none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0) wildcard 1 not used (0) not used (0)
4.1.1.1. Normal Encoding: No Functions Selected 5.1.1.1. Function 0: No-op
If the function ID field (1st octet) is equal to zero, the the 'op1' and 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 'op2' fields (2nd and 3rd octets) must also be equal to zero. This
special value indicates that no functions are applied to the protocol special value indicates that no functions are applied to the protocol
identifier encoded in the remaining octets. The identifier represents a identifier encoded in the remaining octets. The identifier represents a
single protocol encapsulation. normal protocol encapsulation.
4.1.1.2. Protocol Wildcard Function 5.1.1.2. Function 1: Protocol Wildcard Function
The wildcard function (function-ID = 1), is used to aggregate counters, The wildcard function (function-ID = 1), is used to aggregate counters,
by using a single protocol value to indicate potentially many MAC layer by using a single protocol value to indicate potentially many base layer
encapsulations of a particular network layer protocol. A encapsulations of a particular network layer protocol. A
protocolDirEntry of this type will match any MAC-layer encapsulation of protocolDirEntry of this type will match any base-layer encapsulation of
the same protocol. the same protocol.
The 'op1' field (2nd octet) is not used and must be set to zero. 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. The 'op2' field (3rd octet) is not used and must be set to zero.
Each wildcard protocol identifier must be defined in terms of a 'base Each wildcard protocol identifier must be defined in terms of a 'base
encapsulation'. This should be as 'standard' as possible for encapsulation'. This should be as 'standard' as possible for
interoperability purposes. If an encapsulation over 'ether2' is interoperability purposes. If an encapsulation over 'ether2' is
permitted, than this should be used as the 'base encapsulation'. permitted, than this should be used as the base encapsulation.
The agent may also be requested to count some or all of the individual The agent may also be requested to count some or all of the individual
encapsulations for the same protocols, in addition to wildcard counting. encapsulations for the same protocols, in addition to wildcard counting.
Note that the RMON-2 MIB does not require that agents maintain counters Note that the RMON-2 MIB [RMON2] does not require that agents maintain
for multiple encapsulations of the same protocol. It is an counters for multiple encapsulations of the same protocol. It is an
Draft RMON Protocol Identifiers January 22, 1996
implementation-specific matter as to how an agent determines which implementation-specific matter as to how an agent determines which
Draft RMON Protocol Identifiers May 1996
protocol combinations to allow in the protocolDirTable at any given protocol combinations to allow in the protocolDirTable at any given
time. time.
4.2. L2 Protocol Identifiers 5.2. Base Layer Protocol Identifiers
The first layer (L2) is mandatory, and defines the MAC encapsulation of The base layer is mandatory, and defines the base encapsulation of the
the packet and any special functions for this identifier. packet and any special functions for this identifier.
There are no suggested protocolDirParameters bits for the MAC layer. There are no suggested protocolDirParameters bits for the base layer.
The suggested ProtocolDirDescr field for the MAC layer is given by the The suggested ProtocolDirDescr field for the base layer is given by the
corresponding "Name" field in the table 4.1 below. However, corresponding "Name" field in the table 4.1 below. However,
implementations are only required to use the appropriate integer implementations are only required to use the appropriate integer
identifier values. identifier values.
The MAC layer protocolDirType field should contain bits set for the For most base layer protocols, the protocolDirType field should contain
'hasChildren(0)' and 'addressRecognitionCapable(1)' attributes, except bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)'
for the special 'wgAssigned' list, which should have no parameter or attributes. However, the special 'wgAssigned' base layer should have no
attribute bits set. parameter or attribute bits set.
Table 4.2 MAC Layer Encoding Values By design, only 255 different base layer encapsulations are supported.
------------------------------------- There are five base encapsulation values defined at this time. New base
encapsulations (e.g. for new media types) are expected to be added over
time.
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID Name ID
------------------ ------------------
ether2 1 ether2 1
llc 2 llc 2
snap 3 snap 3
vsnap 4 vsnap 4
wgAssigned 5 wgAssigned 5
4.2.1. Ether2 Encapsulation 5.2.1. Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER ether2 PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
Draft RMON Protocol Identifiers May 1996
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
Draft RMON Protocol Identifiers January 22, 1996
"DIX Ethernet, also called Ethernet-II." "DIX Ethernet, also called Ethernet-II."
CHILDREN CHILDREN
"The Ethernet-II type field is used to select child protocols. "The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field. the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the MSB and 'a' and 'b' are the network byte order encodings of the MSB and
LSB of the Ethernet-II type value. LSB of the Ethernet-II type value.
skipping to change at page 20, line 31 skipping to change at page 24, line 35
Children of are named as 'ether2' followed by the type field Children of are named as 'ether2' followed by the type field
value in hexadecimal. The above example would be declared as: value in hexadecimal. The above example would be declared as:
ether2 0x0800" ether2 0x0800"
ADDRESS-FORMAT ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order." "Ethernet addresses are 6 octets in network order."
DECODING DECODING
"Only type values greater than or equal to 1500 decimal indicate "Only type values greater than or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)." (see below)."
REFERENCE REFERENCE
"RFC 894; "A Standard for the Transmission of IP Datagrams over Ethernet
The authoritative list of Ether Type values is identified Networks; RFC 894 [RFC894].
by the URL:
The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 } ::= { 1 }
4.2.2. LLC Encapsulation 5.2.2. LLC Encapsulation
llc PROTOCOL-IDENTIFIER llc PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
Draft RMON Protocol Identifiers May 1996
DESCRIPTION DESCRIPTION
"The LLC (802.2) protocol." "The LLC (802.2) protocol."
CHILDREN CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) are "The LLC SSAP and DSAP (Source/Dest Service Access Points) are
used to select child protocols. Each of these is one octet long, used to select child protocols. Each of these is one octet long,
Draft RMON Protocol Identifiers January 22, 1996
although the least significant bit is a control bit and should be although the least significant bit is a control bit and should be
masked out in most situations. Typically SSAP and DSAP (once masked out in most situations. Typically SSAP and DSAP (once
masked) are the same for a given protocol - each end implicitly masked) are the same for a given protocol - each end implicitly
knows whether it is the server or client in a client/server knows whether it is the server or client in a client/server
protocol. This is only a convention, however, and it is possible protocol. This is only a convention, however, and it is possible
for them to be different. The SSAP is matched against child for them to be different. The SSAP is matched against child
protocols first. If none is found then the DSAP is matched protocols first. If none is found then the DSAP is matched
instead. The child protocol is deemed to start at the first instead. The child protocol is deemed to start at the first
octet after the LLC control field(s). octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol 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 identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
value which maps to the child protocol. For example, a the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of: protocolDirID-fragment value of:
0.0.0.2.0.0.0.240 0.0.0.2.0.0.0.240
defines NetBios over LLC. defines NetBios over LLC.
Children are named as 'llc' followed by the SAP value in Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named: hexadecimal. So the above example would have been named:
llc 0xf0" llc 0xf0"
ADDRESS-FORMAT ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network "The address consists of 6 octets of MAC address in network
skipping to change at page 21, line 47 skipping to change at page 26, line 4
LLC can be present on several different media. For 802.3 and LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw802.3 802.5 its presence is mandated (but see ether2 and raw802.3
encapsulations). For 802.5 there is no other link layer encapsulations). For 802.5 there is no other link layer
protocol. protocol.
Notice also that the raw802.3 link layer protocol may take Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that 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 it may not be possible to utilize all LSAP values if raw802.3 is
also present." also present."
REFERENCE
"IEEE 802.2 - [TBD]
The authoritative list of LLC LSAP values is controlled by the IEEE
Registration Authority:
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority IEEE Registration Authority
c/o Iris Ringel c/o Iris Ringel
IEEE Standards Dept IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331 445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331 Piscataway, NJ 08855-1331
Phone +1 908 562 3813 Phone +1 908 562 3813
Fax: +1 908 562 1571" Fax: +1 908 562 1571"
::= { 2 } ::= { 2 }
4.2.3. SNAP over LLC (OUI=000) Encapsulation 5.2.3. SNAP over LLC (OUI=000) Encapsulation
snap PROTOCOL-IDENTIFIER snap PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC "The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC." restricted to LLC."
CHILDREN CHILDREN
"Children of 'snap' are identified by Ethernet-II type values; "Children of 'snap' are identified by Ethernet-II type values;
skipping to change at page 22, line 50 skipping to change at page 27, line 4
0.0.0.3.0.0.8.0 0.0.0.3.0.0.8.0
defines the IP/SNAP protocol. defines the IP/SNAP protocol.
Children of this protocol are named 'snap' followed by the Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would Ethernet-II type value in hexadecimal. The above example would
be named: be named:
snap 0x0800" snap 0x0800"
ADDRESS-FORMAT ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA "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 and a single control octet will be present. There are then three
octets of OUI and two octets of PID. For this encapsulation the octets of OUI and two octets of PID. For this encapsulation the
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)." OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
REFERENCE REFERENCE
"[TBD]" "SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
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"
::= { 3 } ::= { 3 }
4.2.4. SNAP over LLC (OUI != 000) Encapsulation 5.2.4. SNAP over LLC (OUI != 000) Encapsulation
vsnap PROTOCOL-IDENTIFIER vsnap PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have "This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that do." a zero OUI. See 'snap' above for details of those that do."
CHILDREN CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is "Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first not parsed; child protocols are deemed to start with the first
skipping to change at page 23, line 43 skipping to change at page 28, line 5
Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network '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 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 value, where the 'd' and 'e' represent the MSB and LSB of the
EtherType, respectively. EtherType, respectively.
For example, a protocolDirID-fragment value of: For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7.0.0.128.155 0.0.0.4.0.8.0.7.0.0.128.155
Draft RMON Protocol Identifiers May 1996
defines the Appletalk Phase 2 protocol over vsnap. defines the Appletalk Phase 2 protocol over vsnap.
Note that two protocolDirParameters octets must be present in Note that two protocolDirParameters octets must be present in
protocolDirTable INDEX values for 'vsnap' protocols. The first protocolDirTable INDEX values for 'vsnap' protocols. The first
protocolDirParameters octet defines the actual parameters. The protocolDirParameters octet defines the actual parameters. The
second protocolDirParameters octet is not used and must be set to second protocolDirParameters octet is not used and must be set to
zero. zero.
Children are named as 'vsnap(<OUI>) <ethertype>', where the Children are named as 'vsnap(<OUI>) <ethertype>', where the
Draft RMON Protocol Identifiers January 22, 1996
'<OUI>' field is represented as 3 octets in hexadecimal notation '<OUI>' field is represented as 3 octets in hexadecimal notation
or the ASCII string associated with the OUI value. The or the ASCII string associated with the OUI value. The
<ethertype> field is represented by the 2 byte EtherType value in <ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named: hexadecimal notation. So the above example would be named:
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b' 'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
ADDRESS-FORMAT ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc' "The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details." protocol identifier for more details."
DECODING DECODING
"Same as for 'snap' except the OUI is non-zero." "Same as for 'snap' except the OUI is non-zero."
REFERENCE REFERENCE
"Same as for 'snap'." "SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
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"
::= { 4 } ::= { 4 }
4.2.5. Working Group Assigned Protocols 5.2.5. Working Group Assigned Protocols
wgAssigned PROTOCOL-IDENTIFIER wgAssigned PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
} ATTRIBUTES { }
ATTRIBUTES {
}
DESCRIPTION DESCRIPTION
This branch contains protocols which do not conform easily to the "This branch contains protocols which do not conform easily to
hierarchical format utilized in the other link layer branches. the hierarchical format utilized in the other link layer
Do not create children of this protocol unless you are sure that branches. Usually, such a protocol 'almost' conforms to a
they cannot be handled by the more conventional link layers
above. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional particular 'well-known' identifier format, but additional
identification criteria are used, preventing any 'well-known' criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic. preventing the any 'well-known'
Draft RMON Protocol Identifiers May 1996
protocol-identifier macro from being used. protocol-identifier macro from being used.
Sometimes well-known protocols are simply remapped to a different Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'user-extensibility' feature of the can be identified with the 'user-extensibility' feature of the
protocolDirTable, and do not need special working group protocolDirTable, and do not need special working group
assignments. assignments.
A centrally located list of these enumerated protocols must be A centrally located list of these enumerated protocols must be
maintained by the RMON working group [ed-- or perhaps IANA] to maintained by the RMON working group to insure interoperability.
insure interoperability. Support for new link-layers will be (See section 3.2 for details on the document update procedure.)
added explicitly, and only protocols which cannot possibly be Support for new link-layers will be added explicitly, and only
represented in a better way will be considered. protocols which cannot possibly be represented in a better way
will be considered as 'wgEnumerated' protocols.
Draft RMON Protocol Identifiers January 22, 1996
Working group protocols are identified by the MAC-layer-selector Working group protocols are identified by the base-layer-selector
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the
integer value corresponding to the particular WG protocol. integer value corresponding to the particular WG protocol.
[ed--the WG must decide if the list should be maintained as a MIB Do not create children of this protocol unless you are sure that
object they cannot be handled by the more conventional link layers
anyway. The enumerated list is included below in the meantime.]" above."
CHILDREN CHILDREN
"Children of this protocol are identified by implementation- "Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING' specific means, described (as best as possible) in the 'DECODING'
clause within the 'PSEUDO-PROTOCOL-IDENTIFIER' for each clause within the protocol-variant-identifier macro for each
enumerated protocol. enumerated protocol.
For example, a protocolDirID-fragment value of: For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1 0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3 defines the IPX protocol encapsulated directly in 802.3
Children are named 'wgAssigned' followed by the name and value of Children are named 'wgAssigned' followed by the name or numeric
the particular enumeration in ASCII Ethernet-II type in of the particular working group assigned protocol. The above
hexadecimal. The above example would be named: example would be named:
'wgAssigned 1' or 'wgAssigned ipxOverRaw8023'"
'wgAssigned ipxOverRaw8023(1)'"
DECODING DECODING
"The 'wgAssigned' link layer is a pseudo-protocol and is not "The 'wgAssigned' base layer is a pseudo-protocol and is not
decoded." decoded."
REFERENCE REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER and PROTOCOL-VARIANT-IDENTIFIER "Refer to individual PROTOCOL-IDENTIFIER macros for information
macros for information on each child of the wgAssigned protocol." on each child of the working group assigned protocol."
::= { 5 }
wgAssignedProtocols OBJECT-TYPE
MAX-ACCESS not-accessible
STATUS current
SYNTAX INTEGER {
ipxOverRaw8023(1)
}
DESCRIPTION
"This enumerated list contains identifiers used in the
naming of protocolDirTable entries."
REFERENCE
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
"Each enumerated protocol is identified in the RMON Protocol ::= { 5 }
Identifiers document [rfcxxxx]."
::= { rmon xxx }
4.2.6. Working Group Enumerated Protocol Identifiers 5.2.5.1. Working Group Assigned Protocol Identifiers
The following protocol encapsulations are identified by the RMON WG in a The following protocol-variant-identifier macro declarations are used to
proprietary way, by simple enumeration. identify the RMONMIB WG assigned protocols in a proprietary way, by
simple enumeration. Note that an additional four-octet layer identifier
may be used for some enumerations (as with the 'vsnap' base-layer
identifier). Refer to the 'CHILDREN' clause in the protocol-identifier
macro for a particular protocol to determine the number of octets in the
'wgAssigned' layer-identifier.
ipxOverRaw8023 PROTOCOL-VARIANT-IDENTIFIER ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF "ipx" VARIANT-OF "ipx"
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over "This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field. 802.3, without a type field.
Refer to the macro for IPX for additional information about this Refer to the macro for IPX for additional information about this
protocol." protocol."
DECODING DECODING
"Whenever the 802.3 header indicates LLC a set of protocol "Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these 'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document." beyond the scope of this document."
::= { wgAssigned 1 } ::= { wgAssigned 1 }
4.3. L3 Protocol Identifiers 5.3. L3: Children of Base Protocol Identifiers
Network layer protocol identifier macros contain additional information Network layer protocol identifier macros contain additional information
about the network layer, and is found immediately following an L2 about the network layer, and is found immediately following a base
layer-identifier in a protocol identifier. layer-identifier in a protocol identifier.
The ProtocolDirParameters supported at the network layer are The ProtocolDirParameters supported at the network layer are
'countsFragments(0)', and 'tracksSessions(1). An agent may choose to 'countsFragments(0)', and 'tracksSessions(1). An agent may choose to
implement a subset of these parameters. implement a subset of these parameters.
The protocol-name should be used for the ProtocolDirDescr field. The The protocol-name should be used for the ProtocolDirDescr field. The
ProtocolDirType ATTRIBUTES used at the network layer are ProtocolDirType ATTRIBUTES used at the network layer are
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose
to implement a subset of these attributes for each protocol, and to implement a subset of these attributes for each protocol, and
Draft RMON Protocol Identifiers May 1996
therefore limit which tables the indicated protocol can be present (e.g. therefore limit which tables the indicated protocol can be present (e.g.
protocol distribution, host, and matrix tables).. protocol distribution, host, and matrix tables)..
Draft RMON Protocol Identifiers January 22, 1996
The following protocol-identifier macro declarations are given for The following protocol-identifier macro declarations are given for
example purposes only. They are not intended to constitute an exhaustive example purposes only. They are not intended to constitute an exhaustive
list or an authoritative source for any of the protocol information list or an authoritative source for any of the protocol information
given. However, any protocol that can encapsulate other protocols must given. However, any protocol that can encapsulate other protocols must
be documented here in order to encode the children identifiers into be documented here in order to encode the children identifiers into
protocolDirID strings. Leaf protocols should be documented as well, but protocolDirID strings. Leaf protocols should be documented as well, but
an implementation can identify a leaf protocol even if it isn't listed an implementation can identify a leaf protocol even if it isn't listed
here (as long as the parent is documented). here (as long as the parent is documented).
4.3.1. IP 5.3.1. IP
ip PROTOCOL-IDENTIFIER ip PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS {
countsFragments(0), -- This parameter applies to all child countsFragments(0) -- This parameter applies to all child
-- protocols. -- protocols.
} }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0),
addressRecognitionCapable(1) addressRecognitionCapable(1)
} }
DESCRIPTION DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note "The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular the following identifiers may be present in a particular
skipping to change at page 27, line 45 skipping to change at page 31, line 47
Assigned Numbers Document. Assigned Numbers Document.
The value of the Protocol field is encoded in an octet string as The value of the Protocol field is encoded in an octet string as
[ 0.0.0.a ], where 'a' is the protocol field . [ 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' Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of: protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1 0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp) defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip "4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
packet contains two addresses, the source address and the
destination address."
DECODING DECODING
"Note: ether2/ip/ipip4/udp is a different protocolDirID than "Note: ether2/ip/ipip4/udp is a different protocolDirID than
ether2/ip/udp, as identified in the protocolDirTable. As such, ether2/ip/udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown): 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/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 " ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE REFERENCE
"RFC 791; "RFC 791 [RFC791] defines the Internet Protocol; The following
The following URL defines the authoritative repository URL defines the authoritative repository for the PROTOCOL NUMBERS
for the PROTOCOL NUMBERS Table: Table:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers" ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= { ::= {
ether2 0x0800, ether2 0x0800,
llc 0x06, llc 0x06,
snap 0x0800, snap 0x0800,
ip 4, ip 4,
ip 94 ip 94
} }
4.3.1.1. Children of IP 5.3.2. IPX
4.3.1.1.1. ICMP ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the
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".
REFERENCE
Draft RMON Protocol Identifiers May 1996
"The IPX protocol is defined by the Novell Corporation
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
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
wgAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}
5.3.3. ARP
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC 826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
5.3.4. IDP
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
Draft RMON Protocol Identifiers May 1996
"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"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}
5.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, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}
5.3.6. Appletalk
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
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."
Draft RMON Protocol Identifiers May 1996
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(0x080007) 0x809b
}
5.4. L4: Children of L3 Protocols
5.4.1. ICMP
icmp PROTOCOL-IDENTIFIER icmp PROTOCOL-IDENTIFIER
PARAMETERS {} PARAMETERS { }
ATTRIBUTES {} ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"Internet Message Control Protocol." "Internet Message Control Protocol."
REFERENCE REFERENCE
"RFC-792" "RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 } ::= { ip 1 }
4.3.1.1.2. TCP 5.4.2. TCP
tcp PROTOCOL-IDENTIFIER tcp PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
hasChildren(0) hasChildren(0)
} }
DESCRIPTION DESCRIPTION
"Transmission Control Protocol." "Transmission Control Protocol."
CHILDREN CHILDREN
Draft RMON Protocol Identifiers January 22, 1996
"Children of TCP are identified by the 16 bit Destination Port "Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC 793. They are encoded as [ 0.0.a.b], 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 Port where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of: example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23 0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)" (ether2.ip.tcp.telnet)"
REFERENCE REFERENCE
"RFC 793;
The following URL defines the authoritative repository Draft RMON Protocol Identifiers May 1996
for reserved and registered TCP port values:
"RFC 793 [RFC793] defines the Trasmission Control Protocol.
The following URL defines the authoritative repository for
reserved and registered TCP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 6 } ::= { ip 6 }
4.3.1.1.3. UDP 5.4.3. UDP
udp PROTOCOL-IDENTIFIER udp PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
}
ATTRIBUTES { ATTRIBUTES {
hasChildren(0) hasChildren(0)
} }
DESCRIPTION DESCRIPTION
"User Datagram Protocol." "User Datagram Protocol."
CHILDREN CHILDREN
"Children of UDP are identified by the 16 bit Destination Port "Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC 768. They are encoded as [ 0.0.a.b ], 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 Destination Port where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of: example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161 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)" identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE REFERENCE
"RFC 768; "RFC 768 [RFC768] defines the User Datagram Protocol.
The following URL defines the authoritative repository
for reserved and registered UDP port values: The following URL defines the authoritative repository for
reserved and registered UDP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 17 } ::= { ip 17 }
Draft RMON Protocol Identifiers January 22, 1996 5.5. L5: Applicataion Layer Protocols
4.3.1.1.3.1. Children of UDP 5.5.1. FTP
Note that some of the following protocols can be encapsulated in 5.5.1.1. FTP-DATA
protocols other than UDP. The assignment section of each protocol- ftp-data PROTOCOL-IDENTIFIER
identifier macro lists any additional encapsulations. PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
4.3.1.1.3.1. SNMP Draft RMON Protocol Identifiers May 1996
snmp PROTOCOL-IDENTIFIER default data-connection port. "
PARAMETERS {} REFERENCE
ATTRIBUTES {} "RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
5.5.1.2. FTP Control
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 "The File Transfer Protocol Control Port; An FTP client initiates
protocol versions. Does not include SNMP trap packets." an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE REFERENCE
"Transport Mappings for SNMPv2: RFC 1449; "RFC 959 [RFC959] defines the File Transfer Protocol."
SNMP over IPX: RFC 1420; ::= { tcp 21 }
SNMP over AppleTalk: RFC 1419;"
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}
4.3.1.1.3.1. SNMPTRAP 5.5.2. Telnet
snmptrap PROTOCOL-IDENTIFIER telnet PROTOCOL-IDENTIFIER
PARAMETERS {} PARAMETERS { }
ATTRIBUTES {} ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"Simple Network Management Protocol Trap Port." "The Telnet Protocol; The purpose of the TELNET Protocol is to
provide a fairly general, bi-directional, eight-bit byte oriented
communications facility. Its primary goal is to allow a standard
method of interfacing terminal devices and terminal-oriented
processes to each other. "
REFERENCE REFERENCE
"Transport Mappings for SNMPv2: RFC 1449; "RFC 854 [RFC854] defines the basic Telnet Protocol."
SNMPv1: RFC 1155, RFC 1157; ::= { tcp 23 }
SNMP over IPX: RFC 1420;
SNMP over AppleTalk: RFC 1419;"
::= {
udp 162,
ipx 0x9010,
atalk 9
}
Draft RMON Protocol Identifiers January 22, 1996 5.5.3. SMTP
4.3.1.1.3.1. TFTP smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC 821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
Draft RMON Protocol Identifiers May 1996
::= { tcp 25 }
5.5.4. DNS
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC 1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }
5.5.5. BOOTP
5.5.5.1. Bootstrap Server Protocol
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }
5.5.5.2. Bootstrap Client Protocol
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }
Draft RMON Protocol Identifiers May 1996
5.5.6. TFTP
tftp PROTOCOL-IDENTIFIER tftp PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS {
tracksSessions(1) tracksSessions(1)
} }
ATTRIBUTES {} ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each "Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets." will be encoded in subsequent packets."
REFERENCE REFERENCE
"RFC 1350; "RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
TFTP Option Extension (RFC 1782) 1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
TFTP Blocksize Option (RFC 1783) defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
TFTP Timeout Interval and Transfer Size Options (RFC 1784) TFTP Timeout Interval and Transfer Size Options."
TFTP Option Negotiation Analysis (RFC 1785)"
::= { udp 69 } ::= { udp 69 }
4.3.2. IPX 5.5.7. HTTP
ipx PROTOCOL-IDENTIFIER www-http PROTOCOL-IDENTIFIER
PARAMETERS { PARAMETERS { }
} ATTRIBUTES { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION DESCRIPTION
"Novell IPX" "Hypertext Transfer Protocol; "
CHILDREN
"Children of IPX are defined by the 16 bit value of the
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 REFERENCE
"Novell [TBD]" "RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0)."
Draft RMON Protocol Identifiers January 22, 1996 ::= { tcp 80 }
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
wgAssigned ipxOverRaw8023(1) -- 0.0.0.1
}
4.3.3. ARP 5.5.8. POP3
arp PROTOCOL-IDENTIFIER pop3 PROTOCOL-IDENTIFIER
PARAMETERS {} PARAMETERS { }
ATTRIBUTES {} ATTRIBUTES { }
DESCRIPTION DESCRIPTION
An Address Resolution Protocol message (request or response). "Post Office Protocol -- Version 3. Clients establish connections
This protocol does not include Reverse ARP (RARP) packets, which with POP3 servers by using this destination port number."
are counted separately.
REFERENCE REFERENCE
"RFC 826" "RFC 1725 [RFC1725] defines Version 3 of the Post Office
::= { Protocol."
ether2 0x806, -- [ 0.0.8.6 ] ::= { tcp 110 }
snap 0x806
}
4.3.4. IDP Draft RMON Protocol Identifiers May 1996
idp PROTOCOL-IDENTIFIER 5.5.9. SUNRPC
PARAMETERS {
} sunrpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { ATTRIBUTES {
hasChildren(0), hasChildren(0) -- port mapper function numbers
addressRecognitionCapable(1) }
}
DESCRIPTION DESCRIPTION
"Xerox IDP" "SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet Specific RPC functions are represented as children of the sunrpc
type field. The value is encoded into an octet string as [ protocol. Each 'RPC function protocol' is identified by its
0.0.0.a ], where 'a' is the value of the packet type field in function number assignment. RPC function number assignments are
network byte order. defined by different naming authorities, depending of the
ADDRESS-FORMAT function identifier value.
"4 bytes of Network number followed by the 6 bytes Host address From [RFC1831]:
each in network byte order".
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'.
REFERENCE REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981" "RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
::= { by the URL:
ether2 0x600, -- [ 0.0.6.0 ] ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
snap 0x600 ::= { udp 111 }
}
4.3.5. Appletalk ARP 5.5.10. NFS
atalkarp PROTOCOL-IDENTIFIER nfs PROTOCOL-IDENTIFIER
PARAMETERS {} PARAMETERS {
ATTRIBUTES {} countsFragments(0)
}
ATTRIBUTES { }
DESCRIPTION DESCRIPTION
"Appletalk Address Resolution Protocol." "Sun Network File System (NFS);"
DECODING
"The first packet in an NFS transaction is sent to the port-
mapper, and therefore decoded statically by monitoring RFC
portmap requests [RFC1831]. Any subsequent NFS fragments must be
decoded and correctly identified by 'remembering' the port
assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
The 'countsFragments(0)' PARAMETER bit is used to indicate
whether the probe can (and should) monitor portmapper activity to
correctly attribute all NFS packets."
REFERENCE REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A." "The NFS Version 3 Protocol Specification is defined in RFC 1813
::= { [RFC1813]."
ether2 0x80f3, -- [ 0.0.128.243 ] ::= {
vsnap(0x080007) 0x80f3 sunrpc 100003 -- [0.1.134.163]
} }
4.3.6. Appletalk 5.5.11. SNMP
atalk PROTOCOL-IDENTIFIER 5.5.11.1. SNMP Request/Response
PARAMETERS { snmp PROTOCOL-IDENTIFIER
} PARAMETERS { }
ATTRIBUTES { ATTRIBUTES { }
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION DESCRIPTION
"AppleTalk Protocol." "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
CHILDREN protocol versions. Does not include SNMP trap packets."
"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 REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A." "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
::= { protocol is defined in RFC 1905 [RFC1905]. Transport mappings
ether2 0x809b, -- [ 0.0.128.155 ] are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
vsnap(0x080007) 0x809b
Draft RMON Protocol Identifiers May 1996
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
} }
Draft RMON Protocol Identifiers January 22, 1996 5.5.11.2. SNMP Trap
5. Acknowledgements snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
ipx 0x9010,
atalk 9
}
6. Acknowledgements
This document was produced by the IETF RMONMIB Working Group. This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their contributions The authors wish to thank the following people for their contributions
to this document: to this document:
Anil Singhal Anil Singhal
Frontier Software Development, Inc. Frontier Software Development, Inc.
anil@frontier.com
Jeanne Haney Jeanne Haney
Bay Networks Bay Networks
jhaney@baynetworks.com
Dan Hansen Dan Hansen
Network General Corp. Network General Corp.
danh@ngc.com
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
6. References 7. References
[RFC1212] [RFC768]
Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", Postel, J., "User Datagram Protocol", STD 6, RFC 768,
RFC 1212, Performance Systems International, Hughes LAN Systems, USC/Information Sciences Institute, August 1980.
March 1991.
[RFC791]
Postel, J., ed., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, USC/Information Sciences
Institute, September 1981.
[RFC792]
Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[RFC793]
Postel, J., "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 793, USC/Information Sciences
Institute, September 1981.
[RFC821]
Postel, J., "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1982.
[RFC826]
Plummer, D., "An Ethernet Address Resolution Protocol or
"Converting Network Protocol Addresses to 48-bit Ethernet Addresses
for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS,
November 1982.
[RFC854]
Postel, J. and Reynolds, J., "Telnet Protocol Specification", RFC
854, ISI, May 1983.
[RFC894]
C.OHornig, "A Standard for the Transmission of IP Datagrams over
Ethernet Networks", RFC 894, Symbolics, April 1984.
[RFC951]
Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsytems, September 1985.
[RFC959]
Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
Draft RMON Protocol Identifiers May 1996
USC/Information Sciences Institute, October 1985.
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1157]
Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[RFC1213] [RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17, for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International, RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991. March 1991.
[RFC1442] [RFC1350]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
of Management Information for version 2 of the Simple Network 1992.
Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes
LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[RFC1445] [RFC1419]
Galvin, J., and K. McCloghrie, "Administrative Model for version 2 Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419,
of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Novell, Inc., Apple Computer, Inc., March 1993.
Trusted Information Systems, Hughes LAN Systems, April 1993.
[RFC1448] [RFC1420]
Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
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] [RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994. USC/Information Sciences Institute, October 1994.
[RFC1725]
Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
[RFC1757] [RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
Mellon University, February 1995. Mellon University, February 1995.
[RFC1782]
Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782,
Xylogics, Inc., Hewlett Packard Co., March 1995.
Draft RMON Protocol Identifiers May 1996
[RFC1783]
Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1784]
Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
1995.
[RFC1800] [RFC1800]
Postel, J., Editor, "Internet Official Protocol Standards", STD 1, Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
RFC 1800, IAB, July 1995. RFC 1800, IAB, July 1995.
[RMON2] [RFC1831]
S. Waldbusser, "Remote Network Monitoring MIB Version 2", draft- Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
1831, Sun Microsystems, Inc., August 1995.
Draft RMON Protocol Identifiers January 22, 1996 [RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
ietf-rmonmib-rmon2-02.txt, International Network Services, October [RFC1903]
1995. SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
Draft RMON Protocol Identifiers January 22, 1996 [RFC1904]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
7. Security Considerations [RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1945]
Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
Draft RMON Protocol Identifiers May 1996
HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995.
[RMON2]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
ietf-rmonmib-rmon2-03.txt, International Network Services, January
1996.
Draft RMON Protocol Identifiers May 1996
8. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
8. Authors' Addresses 9. Authors' Addresses
Andy Bierman Andy Bierman
Bierman Consulting Cisco Systems, Inc.
1200 Sagamore Lane 170 West Tasman Drive
Ventura, CA 93001 San Jose, CA 95134
Phone: 805-648-2028 Phone: 408-527-3711
Email: abierman@west.net Email: abierman@cisco.com
Robin Iddon Robin Iddon
AXON Networks, Inc. 3Com/AXON
[TBD] 40/50 Blackfrias Street
Phone: [TBD] Edinburgh, UK
Phone: +44 131.558.3888
Email: robini@axon.com Email: robini@axon.com
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
1.1 The SNMPv1 Network Management Framework ....................... 2 2 The SNMP Network Management Framework ........................... 3
1.1.1 Object Definitions .......................................... 2 2.1 Object Definitions ............................................ 3
2 Overview ........................................................ 3 3 Overview ........................................................ 4
2.1 Terms ......................................................... 3 3.1 Terms ......................................................... 4
2.2 Relationship to the Remote Network Monitoring MIB ............. 5 3.2 Relationship to the Remote Network Monitoring MIB ............. 6
2.3 Relationship to the Other MIBs ................................ 5 3.3 Relationship to the Other MIBs ................................ 7
3 Protocol Identifier Encoding .................................... 6 4 Protocol Identifier Encoding .................................... 8
3.1 ProtocolDirTable INDEX Format Examples ........................ 9 4.1 ProtocolDirTable INDEX Format Examples ........................ 11
3.2 Protocol Identifier Macro Format .............................. 9 4.2 Protocol Identifier Macro Format .............................. 11
3.2.1 Mapping of the Protocol Name ................................ 10 4.2.1 Mapping of the Protocol Name ................................ 14
3.2.2 Mapping of the Protocol Variant Name ........................ 10 4.2.2 Mapping of the VARIANT-OF Clause ............................ 14
3.2.3 Mapping of the PARAMETERS Clause ............................ 11 4.2.3 Mapping of the PARAMETERS Clause ............................ 15
3.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 12 4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 16
3.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 12 4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 16
3.2.4 Mapping of the VARIANT-OF Clause ............................ 13 4.2.4 Mapping of the ATTRIBUTES Clause ............................ 17
3.2.5 Mapping of the ATTRIBUTES Clause ............................ 13 4.2.5 Mapping of the DESCRIPTION Clause ........................... 18
3.2.6 Mapping of the DESCRIPTION Clause ........................... 14 4.2.6 Mapping of the CHILDREN Clause .............................. 18
3.2.7 Mapping of the CHILDREN Clause .............................. 14 4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 19
3.2.8 Mapping of the ADDRESS-FORMAT Clause ........................ 15 4.2.8 Mapping of the DECODING Clause .............................. 19
3.2.9 Mapping of the DECODING Clause .............................. 15 4.2.9 Mapping of the REFERENCE Clause ............................. 19
3.2.10 Mapping of the REFERENCE Clause ............................ 15 4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 20
3.2.11 Evaluating a Protocol-Identifier INDEX ..................... 16 5 Protocol Identifier Macros ...................................... 21
4 Protocol Identifier Macros ...................................... 17 5.1 Base Identifier Encoding ...................................... 21
4.1 Base Identifier Encoding ...................................... 17 5.1.1 Protocol Identifier Functions ............................... 21
4.1.1 Protocol Identifier Functions ............................... 17 5.1.1.1 Function 0: No-op ......................................... 22
4.1.1.1 Normal Encoding: No Functions Selected .................... 18 5.1.1.2 Function 1: Protocol Wildcard Function .................... 22
4.1.1.2 Protocol Wildcard Function ................................ 18 5.2 Base Layer Protocol Identifiers ............................... 23
4.2 L2 Protocol Identifiers ....................................... 19 5.2.1 Ether2 Encapsulation ........................................ 23
4.2.1 Ether2 Encapsulation ........................................ 19 5.2.2 LLC Encapsulation ........................................... 24
4.2.2 LLC Encapsulation ........................................... 20 5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 26
4.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 22 5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 27
4.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 23 5.2.5 Working Group Assigned Protocols ............................ 28
4.2.5 Working Group Assigned Protocols ............................ 24 5.2.5.1 Working Group Assigned Protocol Identifiers ............... 30
4.2.6 Working Group Enumerated Protocol Identifiers ............... 26 5.3 L3: Children of Base Protocol Identifiers ..................... 30
4.3 L3 Protocol Identifiers ....................................... 26 5.3.1 IP .......................................................... 31
4.3.1 IP .......................................................... 27 5.3.2 IPX ......................................................... 32
4.3.1.1 Children of IP ............................................ 28 5.3.3 ARP ......................................................... 33
4.3.1.1.1 ICMP .................................................... 28 5.3.4 IDP ......................................................... 33
4.3.1.1.2 TCP ..................................................... 28 5.3.5 Appletalk ARP ............................................... 34
4.3.1.1.3 UDP ..................................................... 29 5.3.6 Appletalk ................................................... 34
4.3.1.1.3.1 Children of UDP ....................................... 30 5.4 L4: Children of L3 Protocols .................................. 35
Draft RMON Protocol Identifiers January 22, 1996 Draft RMON Protocol Identifiers May 1996
4.3.1.1.3.1 SNMP .................................................. 30 5.4.1 ICMP ........................................................ 35
4.3.1.1.3.1 SNMPTRAP .............................................. 30 5.4.2 TCP ......................................................... 35
4.3.1.1.3.1 TFTP .................................................. 31 5.4.3 UDP ......................................................... 36
4.3.2 IPX ......................................................... 31 5.5 L5: Applicataion Layer Protocols .............................. 36
4.3.3 ARP ......................................................... 32 5.5.1 FTP ......................................................... 36
4.3.4 IDP ......................................................... 32 5.5.1.1 FTP-DATA .................................................. 36
4.3.5 Appletalk ARP ............................................... 33 5.5.1.2 FTP Control ............................................... 37
4.3.6 Appletalk ................................................... 33 5.5.2 Telnet ...................................................... 37
5 Acknowledgements ................................................ 34 5.5.3 SMTP ........................................................ 37
6 References ...................................................... 35 5.5.4 DNS ......................................................... 38
7 Security Considerations ......................................... 37 5.5.5 BOOTP ....................................................... 38
8 Authors' Addresses .............................................. 37 5.5.5.1 Bootstrap Server Protocol ................................. 38
5.5.5.2 Bootstrap Client Protocol ................................. 38
5.5.6 TFTP ........................................................ 39
5.5.7 HTTP ........................................................ 39
5.5.8 POP3 ........................................................ 39
5.5.9 SUNRPC ...................................................... 40
5.5.10 NFS ........................................................ 41
5.5.11 SNMP ....................................................... 41
5.5.11.1 SNMP Request/Response .................................... 41
5.5.11.2 SNMP Trap ................................................ 42
6 Acknowledgements ................................................ 42
7 References ...................................................... 43
8 Security Considerations ......................................... 47
9 Authors' Addresses .............................................. 47
 End of changes. 225 change blocks. 
514 lines changed or deleted 938 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/