One document matched: draft-ietf-rmonmib-rmonprot-v2-01.txt
Differences from draft-ietf-rmonmib-rmonprot-v2-00.txt
Draft RMON Protocol Identifiers July 1997
Remote Network Monitoring MIB Protocol Identifiers
<draft-ietf-rmonmib-rmonprot-v2-01.txt>
July 21, 1997
Andy Bierman
Cisco Systems, Inc.
abierman@cisco.com
Chris Bucci
Network General Corporation
buccic@ngc.com
Robin Iddon
3Com, Inc.
Robin_Iddon@3mail.3com.com
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Bierman/Bucci/Iddon Expires January, 1998 [Page 1]
Draft RMON Protocol Identifiers July 1997
1. Introduction
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes the algorithms required to
identify different protocol encapsulations managed with the Remote
Network Monitoring MIB Version 2 [RFC2021]. Although related to the
original Remote Network Monitoring MIB [RFC1757], this document refers
only to objects found in the RMON-2 MIB.
2. The SNMP Network Management Framework xo.lp The SNMP Network
Management Framework presently consists of three major components. They
are:
o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
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
experimentation and evaluation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the
SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
an administratively assigned name. The object type together with an
object instance serves to uniquely identify a specific instantiation of
the object. For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type.
Bierman/Bucci/Iddon Expires January, 1998 [Page 2]
Draft RMON Protocol Identifiers July 1997
3. Overview
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to
globally identify individual protocol encapsulations in the
protocolDirTable.
This guide contains algorithms and examples of protocol identifier
encapsulations for use as INDEX values in the protocolDirTable.
This document is not intended to be an authoritative reference on the
protocols described herein. Refer to the Official Internet Standards
document [RFC1800], the Assigned Numbers document [RFC1700], or other
appropriate RFCs, IEEE documents, etc. for complete and authoritative
protocol information.
This is the the second revision of this document, and is intended to
replace the first RMON-2 Protocol Identifiers document, defined in RFC
2074 [RFC2074].
3.1. Terms
Several terms are used throughout this document, as well as in the
RMON-2 MIB [RFC2021], that should be introduced:
layer-identifier:
An octet string fragment representing a particular protocol
encapsulation layer. A string fragment identifying a particular
protocol encapsulation layer. This string is exactly four octets,
encoded in network byte order. A particular protocol encapsulation
can be identified by starting with a base layer encapsulation (see
the 'Base Protocol Identifiers' section for more detail), and
following the encoding rules specified in the CHILDREN clause and
assignment section for that layer. Then repeat for each identified
layer in the encapsulation. (See section 4.3 'Evaluating a
Protocol-Identifier INDEX' for more detail.)
protocol:
A particular protocol layer, as specified by encoding rules in this
document. Usually refers to a single layer in a given
encapsulation. Note that this term is sometimes used in the RMON-2
MIB [RFC2021] to name a fully-specified protocol-identifier string.
In such a case, the protocol-identifier string is named for its
upper-most layer. A named protocol may also refer to any
encapsulation of that protocol.
Bierman/Bucci/Iddon Expires January, 1998 [Page 3]
Draft RMON Protocol Identifiers July 1997
protocol-identifier string:
An octet string representing a particular protocol encapsulation,
as specified by encoding rules in this document. This string is
identified in the RMON-2 MIB [RFC2021] as the protocolDirID object.
A protocol-identifier string is composed of one or more layer-
identifiers.
protocol-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RFC2021] (also called a "PI macro").
The PI macro serves several purposes:
- Name the protocol for use within the RMON-2 MIB [RFC2021].
- Describe how the protocol is encoded into an octet string.
- Describe how child protocols are identified (if applicable),
and encoded into an octet string.
- Describe which protocolDirParameters are allowed for the protocol.
- Describe how the associated protocolDirType object is encoded
for the protocol.
- Provide reference(s) to authoritative documentation for the
protocol.
protocol-variant-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RFC2021]. This protocol is a variant
of a well known encapsulation that may be present in the
protocolDirTable. This macro is used to document the IANA assigned
protocols, which are needed to identify protocols which cannot be
practically identified by examination of 'appropriate network
traffic' (e.g. the packets which carry them). All other protocols
(which can be identified by examination of appropriate network
traffic) should be documented using the protocol-identifier macro.
A protocol-variant-identifier is documented using the protocol-
variant version of the protocol-identifier macro.
protocol-parameter:
A single octet, corresponding to a specific layer-identifier in the
protocol-identifier. This octet is a bit-mask indicating special
functions or capabilities that this agent is providing for the
corresponding protocol.
protocol-parameters string:
An octet string, which contains one protocol-parameter for each
layer-identifier in the protocol-identifier. See the section
Bierman/Bucci/Iddon Expires January, 1998 [Page 4]
Draft RMON Protocol Identifiers July 1997
'Mapping of the PARAMETERS Clause' for more detail. This string is
identified in the RMON-2 MIB [RFC2021] as the protocolDirParameters
object.
protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair
that have been converted to an INDEX value, according to the
encoding rules in in section 7.7 of RFC 1902 [RFC1902].
pseudo-protocol:
A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings.
3.2. Relationship to the Remote Network Monitoring MIB
This document is intended to identify possible string values for the
OCTET STRING objects protocolDirID and protocolDirParameters. Tables in
the new Protocol Distribution, Host, and Matrix groups use a local
INTEGER INDEX, in order to remain unaffected by changes in this
document. Only the protocolDirTable uses the strings (protocolDirID and
protocolDirParameters) described in this document.
This document is not intended to limit the protocols that may be
identified for counting in the RMON-2 MIB. Many protocol encapsulations,
not explicitly identified in this document, may be present in an actual
implementation of the protocolDirTable. Also, implementations of the
protocolDirTable may not include all the protocols identified in the
example section below. Note that in implementation, children of TCP
maybe rooted under UDP instead of, or in addition to, TCP (vise versa
for children of UDP).
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.
Macros submissions will be collected in the IANA's MIB files under the
directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the
RMONMIB working group mailing list message archive file
"ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib".
This document does not discuss auto-discovery and auto-population of the
protocolDirTable. This functionality is not explicitly defined by the
Bierman/Bucci/Iddon Expires January, 1998 [Page 5]
Draft RMON Protocol Identifiers July 1997
RMON standard. An agent should populate the directory with 'interesting'
protocols--depending on the intended applications.
3.3. Relationship to the ATM-RMON MIB
The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM
Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides RMON-
like stats, host, matrix, and matrixTopN capability for NSAP address-
based (AAL-5) cell traffic.
3.3.1. Port Aggregation
It it possible to correlate ATM-RMON MIB data with packet-based RMON2
[RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and
'portSelTable' are configured to provide the same level of port
aggregation as used in the packet-based collection. This will require
an ATM-RMON 'portSelectGroup' to contain a single port, in the case of
traditional RMON dataSources, but near-future RMON MIBs will provide
dataSource aggregation mechanisms.
3.3.2. Encapsulation Mappings
The RMON PI document does not contain explicit PI macro support for
"Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or
ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead,
a probe must 'fit' the ATM encapsulation to one of the base layers
defined in this document (i.e., llc, snap, or vsnap), regardless of how
the raw data is obtained by the agent (e.g., VC-muxing vs. LLC-muxing,
or routed vs. bridged formats). See section 5.2 for details on
identifying and decoding a particular base layer.
An NMS can determine some of the omitted encapsulation details by
examining the interface type (ifType) of the dataSource for a particular
RMON collection:
RFC 1483 dataSource ifTypes:
- aal5(49)
LANE dataSource ifTypes:
- aflane8023(59)
- aflane8025(60)
These dataSources require implementation of the ifStackTable from the
new Interfaces MIB [RFC1573]. It is possible that some implementations
Bierman/Bucci/Iddon Expires January, 1998 [Page 6]
Draft RMON Protocol Identifiers July 1997
will use dataSource values which indicate an ifType of 'atm(37)'
(because the ifStackTable is not supported), however this is strongly
discouraged by the RMONMIB WG.
3.3.3. Counting ATM Traffic in RMON2 Collections
The RMON2 AL and NL (host/matrix/topN) tables require that octet
counters be incremented by the size of the particular frame, not by the
size of the frame attributed to a given protocol.
Probe implementations must use the AAL-5 frame size (not the AAL-5
payload size or encapsulated MAC frame size) as the 'frame size' for the
purpose of incrementing RMON2 octet counters (e.g., 'nlHostInOctets',
'alHostOutOctets').
The RMONMIB WG has not addressed issues relating to packet capture of
AAL-5 based traffic. Therefore, it is an implementation-specific matter
whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3 or 802.5
traffic, or LANE traffic) are represented in the RMON1
'captureBufferPacketData' MIB object. Normally, the first octet of the
captured frame is the first octet of the destination MAC address (DA).
3.4. Relationship to the Other MIBs
The RMON Protocol Identifiers document is intended for use with the
protocolDirTable within the RMON MIB. It is not relevant to any other
MIB, or intended for use with any other MIB.
Bierman/Bucci/Iddon Expires January, 1998 [Page 7]
Draft RMON Protocol Identifiers July 1997
4. Protocol Identifier Encoding
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and
protocolDirParameters. To encode the table index, each variable-length
string is converted to an OBJECT IDENTIFIER fragment, according to the
encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index
fragments are simply concatenated. (Refer to figures 1a - 1d below for
more detail.)
The first OCTET STRING (protocolDirID) is composed of one or more 4-
octet "layer-identifiers". The entire string uniquely identifies a
particular protocol encapsulation tree. The second OCTET STRING,
(protocolDirParameters) which contains a corresponding number of 1-octet
protocol-specific parameters, one for each 4-octet layer-identifier in
the first string.
A protocol layer is normally identified by a single 32-bit value. Each
layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as
four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of
the 32-bit value in network byte order. If a particular protocol layer
cannot be encoded into 32 bits, then it must be defined as an
'ianaAssigned' protocol (see below for details on IANA assigned
protocols).
Bierman/Bucci/Iddon Expires January, 1998 [Page 8]
Draft RMON Protocol Identifiers July 1997
The following figures show the differences between the OBJECT IDENTIFIER
and OCTET STRING encoding of the protocol identifier string.
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note
Bierman/Bucci/Iddon Expires January, 1998 [Page 9]
Draft RMON Protocol Identifiers July 1997
that the layer following the base layer usually identifies
a network layer protocol, but this is not always the case,
(most notably for children of the 'vsnap' base-layer).
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note
that the layer following the base layer usually identifies
a network layer protocol, but this is not always the case,
Although this example indicates four encapsulated protocols, in
practice, any non-zero number of layer-identifiers may be present,
theoretically limited only by OBJECT IDENTIFIER length restrictions, as
specified in section 3.5 of RFC 1902 [RFC1902].
Note that these two strings would not be concatenated together if ever
returned in a GetResponse PDU, since they are different MIB objects.
However, protocolDirID and protocolDirParameters are not currently
readable MIB objects.
Bierman/Bucci/Iddon Expires January, 1998 [Page 10]
Draft RMON Protocol Identifiers July 1997
4.1. ProtocolDirTable INDEX Format Examples
The following PI identifier fragments are examples of some fully encoded
protocolDirTable INDEX values for various encapsulations.
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023
ianaAssigned.ipxOverRaw8023.snmp =
12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over UDP/IP over any link layer
ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2
ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether2
ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over vsnap
vsnap.apple-oui.atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
Bierman/Bucci/Iddon Expires January, 1998 [Page 11]
Draft RMON Protocol Identifiers July 1997
4.2. Protocol Identifier Macro Format
The following example is meant to introduce the protocol-identifier
macro. (The syntax is not quite ASN.1.) This macro is used to represent
both protocols and protocol-variants.
If the 'VariantOfPart' component of the macro is present, then the macro
represents a protocol-variant instead of a protocol. A protocol-
variant-identifier is used only for IANA assigned protocols, enumerated
under the 'ianaAssigned' base-layer.
4.2.1. Lexical Conventions
The lexical conventions of the PI language follow the lexical
conventions for the MIB module language. However, the keywords of the PI
language are the following and not those used in the MIB module
language:
ADDRESS-FORMAT
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
The PI language contains only a sub-set of the punctuation elements of
the MIB module language. These elements are:
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
: colon
::= two colons and an equal sign
The following punctuation elements of the MIB module language are not
elements of the PI language:
- hyphen (dash)
. period
Bierman/Bucci/Iddon Expires January, 1998 [Page 12]
Draft RMON Protocol Identifiers July 1997
; semicolon
| vertical bar
.. two periods
4.2.2. Notation for Syntax Descriptions
An extended form of the BNF notation is used to specify the syntax of
the PI language. The rules for this notation are shown below:
* Literal values are specified in quotes, for example "BEGIN"
* Replaceable items are surrounded by less than (<) and greater than
(>) characters, for example <oidValue>
* Defined items are specified without surrounding quotes or less than
and greater than characters, for example lcName
* A vertical bar (|) is used to indicate a choice between items, for
example <synType> | <tcType> | <seqEnum> | <seqBits>
* Ellipsis are used to indicate that the previous item may be
repeated one or more times, for example <importsFrom>...
* Square brackets are used to enclose optional items, for example [
"DISPLAY-HINT" chrStr ]
* Curly braces are used to group together items, for example {
"OBJECT" "IDENTIFIER" }
* An equals character (=) is used to mean "defined as," for example
<mibFile> = <mibModule>...
* An example of a combined usage of several rules is the following:
<importsFrom> = <importsName> ["," <importsName>]...
"FROM" <moduleIdent>
This example uses an equals character to specify that an <importsFrom>
item is defined as the list of items to the right of the equals
character. The square brackets are used to indicate that a comma
followed by an <importsName> item is optional. The ellipsis are used to
indicate that the preceding item, that is, ["," <importsName>] may be
repeated. The text FROM is in quotes to indicate that it is a literal
value.
Bierman/Bucci/Iddon Expires January, 1998 [Page 13]
Draft RMON Protocol Identifiers July 1997
4.2.3. Grammar for the PI Language
The following are "defined items" or "terminals" of the grammar and are
identical to the same lexical elements from the MIB module language,
except for hstr:
lcname - name starting with a lower-case letter
ucname - name starting with an upper-case letter
number - an unsigned decimal number between 0 and 4g-1
hstr - an unsigned hexadecimal number 0 and 4g-1
(note: the format is that used in the C programming
language, and not that used in ASN.1)
string - a quoted string
The following is the extended BNF notation for the grammar with starting
symbol <piFile> [ed. 'firstProtoChar' and 'hex-digit' set notation may
be wrong]:
-- a file containing one or more Protocol Identifier (PI) definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name
<protoName> = <firstProtoChar>[<protoChar>]...
<protoChar> = <firstProtoChar> | "-" | "_" | "*" | "+"
-- the first protoName char limited
<firstProtoChar> = {"a".."z"} | {"A".."Z"} | {"0".."9"}
-- a list of parameters
<parmList> = <parm> [ "," <parm> ]...
Bierman/Bucci/Iddon Expires January, 1998 [Page 14]
Draft RMON Protocol Identifiers July 1997
-- a parameter
<parm> = lcname "(" <nonNegNum> ")"
-- list of attributes
<attrList> = <attr> [ "," <attr> ]...
-- an attribute
<attr> = lcname "(" <nonNegNum> ")"
-- a non-negative number
<nonNegNum> = number | hstr | bstr
-- a hexadecimal constant in 'ANSI C' format
<hstr> = <hex-prefix><hex-num>
<hex-prefix> = "0x" | "0X"
<hex-num> = <hex-digit>...
<hex-digit> = {"0".."9"} | {"a".."f"} | {"A".."F"}
-- list of encapsulation values
<encapList> = <encapValue> [ "," <encapValue> ]...
-- an encapsulation value
<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value
<baseEncapValue> = <nonNegNum>
-- normal encapsulation value
<normalEncapValue> = <protoName> <nonNegNum> [ ":" <nonNegNum> ]...
4.2.4. Mapping of the Protocol Name
The "protoName" value, called the "protocol name" shall be an ASCII
string consisting of one up to 64 characters from the following:
"A" through "Z"
"a" through "z"
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
Bierman/Bucci/Iddon Expires January, 1998 [Page 15]
Draft RMON Protocol Identifiers July 1997
plus(+)
The first character of the protocol name is limited to one of the
following:
"A" through "Z"
"a" through "z"
"0" through "9"
This value should be the name or acronym identifying the protocol. Note
that case is significant. The value selected for the protocol name
should match the "most well-known" name or acronym for the indicated
protocol. For example, the document indicated by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for
children of IP should be given names consistent with the protocol names
found in this authoritative document. Likewise for the port number name
assignments found in:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
When the "well-known name" contains characters not allowed in protocol
names, they must be changed to a dash character ("-") . In the event
that the first character must be changed, the protocol name is prepended
with the letter "p", so the former first letter may be changed to a
dash.
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The
following protocol names are legal:
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
Note that it is possible in actual implementation that different
encapsulations of the same protocol (which are represented by different
entries in the protocolDirTable) will be assigned the same protocol
name.
4.2.5. Mapping of the VARIANT-OF Clause
This clause is present for IANA assigned protocols only. It identifies
the protocol-identifier macro that most closely represents this
particular protocol, and is known as the "reference protocol". (A
protocol-identifier macro must exist for the reference protocol.) When
Bierman/Bucci/Iddon Expires January, 1998 [Page 16]
Draft RMON Protocol Identifiers July 1997
this clause is present in a protocol-identifier macro, the macro is
called a 'protocol-variant-identifier'.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-
identifier macro should not be duplicated in the protocol-variant-
identifier macro, if the 'variant' protocols' semantics are identical
for a given clause.
Since the PARAMETERS and ATTRIBUTES clauses must be present in a
protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e.
"PARAMETERS {}") must be present in a protocol-variant-identifier macro,
and the 'ParamList' and 'AttrList' found in the reference protocol-
identifier macro examined instead.
Note that if an 'ianaAssigned' protocol is defined that is not a variant
of any other documented protocol, then the protocol-identifier macro
should be used instead of the protocol-variant-identifier version of the
macro.
4.2.6. Mapping of the PARAMETERS Clause
The protocolDirParameters object provides an NMS the ability to turn on
and off expensive probe resources. An agent may support a given
parameter all the time, not at all, or subject to current resource load.
The PARAMETERS clause is a list of bit definitions which can be directly
encoded into the associated ProtocolDirParameters octet in network byte
order. Zero or more bit definitions may be present. Only bits 0-7 are
valid encoding values. This clause defines the entire BIT set allowed
for a given protocol. A conforming agent may choose to implement a
subset of zero or more of these PARAMETERS.
Bierman/Bucci/Iddon Expires January, 1998 [Page 17]
Draft RMON Protocol Identifiers July 1997
By convention, the following common bit definitions are used by
different protocols. These bit positions must not be used for other
parameters. They should be reserved if not used by a given protocol.
Bits are encoded in network-byte order.
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause must be present in all protocol-identifier macro
declarations, but may be equal to zero (empty). Note that an NMS must
determine if a given PARAMETER bit is supported by attempting to create
the desired protocolDirEntry The associated ATTRIBUTE bits for
'countsFragments' and 'tracksSessions' do not exist.
4.2.6.1. Mapping of the 'countsFragments(0)' BIT
This bit indicates whether the probe is correctly attributing all
fragmented packets of the specified protocol, even if individual frames
carrying this protocol cannot be identified as such. Note that the
probe is not required to actually present any re-assembled datagrams
(for address-analysis, filtering, or any other purpose) to the NMS.
This bit may only be set in a protocolDirParameters octet which
corresponds to a protocol that supports fragmentation and reassembly in
some form. Note that TCP packets are not considered 'fragmented-streams'
and so TCP is not eligible.
This bit may be set in at most one protocolDirParameters octet within a
protocolDirTable INDEX.
Bierman/Bucci/Iddon Expires January, 1998 [Page 18]
Draft RMON Protocol Identifiers July 1997
4.2.6.2. Mapping of the 'tracksSessions(1)' BIT
The 'tracksSessions(1)' bit indicates whether frames which are part of
remapped-sessions (e.g. TFTP download sessions) are correctly counted by
the probe. For such a protocol, the probe must usually analyze all
packets received on the indicated interface, and maintain some state
information, (e.g. the remapped UDP port number for TFTP).
The semantics of the 'tracksSessions' parameter are independent of the
other protocolDirParameters definitions, so this parameter may be
combined with any other legal parameter configurations.
4.2.7. Mapping of the ATTRIBUTES Clause
The protocolDirType object provides an NMS with an indication of a
probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol.
The ATTRIBUTES clause is a list of bit definitions which are encoded
into the associated instance of ProtocolDirType. The BIT definitions are
specified in the SYNTAX clause of the protocolDirType MIB object.
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
The ATTRIBUTES clause must be present in all protocol-identifier macro
declarations, but may be empty.
4.2.8. Mapping of the DESCRIPTION Clause
The DESCRIPTION clause provides a textual description of the protocol
identified by this macro. Notice that it should not contain details
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
REFERENCE clauses.
Bierman/Bucci/Iddon Expires January, 1998 [Page 19]
Draft RMON Protocol Identifiers July 1997
The DESCRIPTION clause must be present in all protocol-identifier macro
declarations.
4.2.9. Mapping of the CHILDREN Clause
The CHILDREN clause provides a description of child protocols for
protocols which support them. It has three sub-sections:
- Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed
- Details on how the value(s) are encoded in the protocol identifier
octet string
- Details on how child protocols are named with respect to their
parent protocol label(s)
The CHILDREN clause must be present in all protocol-identifier macro
declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES
clause.
4.2.10. Mapping of the ADDRESS-FORMAT Clause
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
format(s) used when encoding addresses.
This clause must be present in all protocol-identifier macro
declarations in which the 'addressRecognitionCapable(1)' BIT is set in
the ATTRIBUTES clause.
4.2.11. Mapping of the DECODING Clause
The DECODING clause provides a description of the decoding procedure for
the specified protocol. It contains useful decoding hints for the
implementor, but should not over-replicate information in documents
cited in the REFERENCE clause. It might contain a complete description
of any decoding information required.
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection as
well as information on determining the start of the child protocol.
For 'addressRecognitionCapable' protocols this includes offset and type
information for the field(s) used to generate addresses.
Bierman/Bucci/Iddon Expires January, 1998 [Page 20]
Draft RMON Protocol Identifiers July 1997
The DECODING clause is optional, and may be omitted if the REFERENCE
clause contains pointers to decoding information for the specified
protocol.
4.2.12. Mapping of the REFERENCE Clause
If a publicly available reference document exists for this protocol it
should be listed here. Typically this will be a URL if possible; if not
then it will be the name and address of the controlling body.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
amount of information which may currently be obtained from an
authoritative document, such as the Assigned Numbers document [RFC1700].
Any duplication or paraphrasing of information should be brief and
consistent with the authoritative document.
The REFERENCE clause is optional, but should be implemented if an
authoritative reference exists for the protocol (especially for standard
protocols).
4.3. Evaluating a Protocol-Identifier INDEX
The following evaluation is done after protocolDirTable INDEX value has
been converted into two OCTET STRINGs according to the INDEX encoding
rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the
protocolDirID, which length should be evenly divisible by four. The
protocolDirParameters length should be exactly one quarter of the
protocolDirID string length.
Protocol-identifier parsing starts with the base layer identifier, which
must be present, and continues for one or more upper layer identifiers,
until all OCTETs of the protocolDirID have been used. Layers may not be
skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can
not exist.
The base-layer-identifier also contains a 'special function identifier'
which may apply to the rest of the protocol identifier.
Wild-carding at the base layer within a protocol encapsulation is the
only supported special function at this time. Refer to the 'Base
Protocol Identifiers' section for wildcard encoding rules.
After the protocol-tree identified in protocolDirID has been parsed,
Bierman/Bucci/Iddon Expires January, 1998 [Page 21]
Draft RMON Protocol Identifiers July 1997
each parameter bit-mask (one octet for each 4-octet layer-identifier) is
evaluated, and applied to the corresponding protocol layer.
A protocol-identifier label may map to more than one value. For
instance, 'ip' maps to 5 distinct values, one for each supported
encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'),
It is important to note that these macros are conceptually expanded at
implementation time, not at run time.
If all the macros are expanded completely by substituting all possible
values of each label for each child protocol, a list of all possible
protocol-identifiers is produced. So 'ip' would result in 5 distinct
protocol-identifiers. Likewise each child of 'ip' would map to at least
5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2,
ip over LLC, etc.).
Bierman/Bucci/Iddon Expires January, 1998 [Page 22]
Draft RMON Protocol Identifiers July 1997
5. Protocol Identifier Macros
The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParameters strings.
The sections defining protocol examples are intended to grow over
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
adding one layer-identifier for each encapsulated protocol.
5.1. Base Identifier Encoding
The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the base layer (e.g.
MAC layer) enumeration value used in this protocol identifier.
The base identifier is encoded as four octets as shown in figure 2.
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table 4.1.
The next two octets ('op1' and 'op2') are operands for the indicated
function. If not used, an operand must be set to zero. The last octet,
'm', is the enumerated value for a particular base layer encapsulation,
found in table 4.2. All four octets are encoded in network-byte-order.
5.1.1. Protocol Identifier Functions
The base layer identifier contains information about any special
functions to perform during collections of this protocol, as well as the
base layer encapsulation identifier.
The first three octets of the identifier contain the function code and
two optional operands. The fourth octet contains the particular base
layer encapsulation used in this protocol (fig. 2).
Bierman/Bucci/Iddon Expires January, 1998 [Page 23]
Draft RMON Protocol Identifiers July 1997
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
5.1.1.1. Function 0: No-op
If the function ID field (1st octet) is equal to zero, the the 'op1' and
'op2' fields (2nd and 3rd octets) must also be equal to zero. This
special value indicates that no functions are applied to the protocol
identifier encoded in the remaining octets. The identifier represents a
normal protocol encapsulation.
5.1.1.2. Function 1: Protocol Wildcard Function
The wildcard function (function-ID = 1), is used to aggregate counters,
by using a single protocol value to indicate potentially many base layer
encapsulations of a particular network layer protocol. A
protocolDirEntry of this type will match any base-layer encapsulation of
the same network layer protocol.
The 'op1' field (2nd octet) is not used and must be set to zero.
The 'op2' field (3rd octet) is not used and must be set to zero.
Each wildcard protocol identifier must be defined in terms of a 'base
encapsulation'. This should be as 'standard' as possible for
interoperability purposes. The lowest possible base layer value should
be chosen. So, if an encapsulation over 'ether2' is permitted, than
this should be used as the base encapsulation.
If not then an encapsulation over LLC should be used, if permitted. And
so on for each of the defined base layers. It should be noted that an
agent does not have to support the non-wildcard protocol identifier over
the same base layer. For instance a token ring only device would not
normally support IP over the ether2 base layer. Nevertheless it should
use the ether2 base layer for defining the wildcard IP encapsulation.
The agent may also be requested to count some or all of the individual
encapsulations for the same protocols, in addition to wildcard counting.
Note that the RMON-2 MIB [RFC2021] does not require that agents maintain
Bierman/Bucci/Iddon Expires January, 1998 [Page 24]
Draft RMON Protocol Identifiers July 1997
counters for multiple encapsulations of the same protocol. It is an
implementation-specific matter as to how an agent determines which
protocol combinations to allow in the protocolDirTable at any given
time.
5.2. Base Layer Protocol Identifiers
The base layer is mandatory, and defines the base encapsulation of the
packet and any special functions for this identifier.
There are no suggested protocolDirParameters bits for the base layer.
The suggested ProtocolDirDescr field for the base layer is given by the
corresponding "Name" field in the table 4.1 below. However,
implementations are only required to use the appropriate integer
identifier values.
For most base layer protocols, the protocolDirType field should contain
bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)'
attributes. However, the special 'ianaAssigned' base layer should have
no parameter or attribute bits set.
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
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
Bierman/Bucci/Iddon Expires January, 1998 [Page 25]
Draft RMON Protocol Identifiers July 1997
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the MSB and
LSB of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
Children of ether2 are named as 'ether2' followed by the type
field value in hexadecimal. The above example would be declared
as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than 1500 decimal indicate Ethernet-II
frames; lower values indicate 802.3 encapsulation (see below)."
REFERENCE
The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
-- LLC Encapsulation
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The LLC (802.2) protocol."
CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) are
Bierman/Bucci/Iddon Expires January, 1998 [Page 26]
Draft RMON Protocol Identifiers July 1997
used to select child protocols. Each of these is one octet long,
although the least significant bit is a control bit and should be
masked out in most situations. Typically SSAP and DSAP (once
masked) are the same for a given protocol - each end implicitly
knows whether it is the server or client in a client/server
protocol. This is only a convention, however, and it is possible
for them to be different. The SSAP is matched against child
protocols first. If none is found then the DSAP is matched
instead. The child protocol is deemed to start at the first
octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
defines NetBios over LLC.
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw 802.3
encapsulations). For 802.5 there is no other link layer
protocol.
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
Bierman/Bucci/Iddon Expires January, 1998 [Page 27]
Draft RMON Protocol Identifiers July 1997
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
-- SNAP over LLC (OUI=000) Encapsulation
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP PID (Protocol Identifier) field is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
are the MSB and LSB of the Ethernet-II type value. For example,
a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"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
Bierman/Bucci/Iddon Expires January, 1998 [Page 28]
Draft RMON Protocol Identifiers July 1997
octets of OUI and two octets of PID. For this encapsulation the
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
REFERENCE
"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 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation
vsnap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that have a
zero OUI value."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the
protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
over vsnap.
Children are named as 'vsnap <OUI>', where the '<OUI>' field is
represented as 3 octets in hexadecimal notation.
So the above example would be named:
'vsnap 0x080007'"
ADDRESS-FORMAT
Bierman/Bucci/Iddon Expires January, 1998 [Page 29]
Draft RMON Protocol Identifiers July 1997
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed."
REFERENCE
"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 }
-- IANA Assigned Protocols
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic (preventing the any 'well-known'
protocol-identifier macro from being used).
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'user-extensibility' feature of the
protocolDirTable, and do not need special IANA assignments.
A centrally located list of these enumerated protocols must be
maintained by IANA to insure interoperability. (See section 3.2
for details on the document update procedure.) Support for new
link-layers will be added explicitly, and only protocols which
cannot possibly be represented in a better way will be considered
as 'ianaAssigned' protocols.
IANA protocols are identified by the base-layer-selector value [
Bierman/Bucci/Iddon Expires January, 1998 [Page 30]
Draft RMON Protocol Identifiers July 1997
0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the integer
value corresponding to the particular IANA protocol.
Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers
above."
CHILDREN
"Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING'
clause within the protocol-variant-identifier macro for each
enumerated protocol.
Children of this protocol are encoded as [ 0.0.0.5 ], the
protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ]
where 'a', 'b' are the network byte order encodings of the MSB
and LSB of the enumeration value for the particular IANA assigned
protocol.
Note that enumeration values are actually defined in the
'encapsList' of each variant-protocol-identifier defined in this
document.
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the numeric value
of the particular IANA assigned protocol. The above example would
be named:
'ianaAssigned 1'
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
-- The following protocol-variant-identifier macro declarations are
-- used to identify the RMONMIB IANA assigned protocols in a proprietary way,
-- by simple enumeration.
Bierman/Bucci/Iddon Expires January, 1998 [Page 31]
Draft RMON Protocol Identifiers July 1997
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF ipx
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q_iana 1 -- [5.0.0.1]
}
5.3. Encapsulation Layers
Encapsulation layers are positioned between the base layer and the
network layer. It is an implementation-specific matter wheter a probe
expose all such encapsulations in its RMON2 Protocol Directory.
5.3.1. IEEE 802.1Q
The emerging VLAN encapsulation standard [IEEE802.1Q][IEEE802.1p],
developed in the IEEE, will mean that RMON probes may encounter 'tagged'
frames on monitored links. This section defines a PI macro which
supports most (but not all) features of the encapsulation.
Most notably, the RMON PI macro '802-1Q' does not expose the 'TR-encaps'
bit in the TCI portion of the VLAN header. It is an implementation
specific matter whether an RMON probe converts LLC-TR formatted frames
to LLC-N format, for the purpose of RMON collection.
In order to support the Ethernet and LLC-N formats in the most efficient
manner, and still maintain alignment with the RMON2 'collapsed' base
layer approach (i.e., support for snap and vsnap), the children of
802dot1Q are encoded a little differently than if the VLAN header was
not present.
Bierman/Bucci/Iddon Expires January, 1998 [Page 32]
Draft RMON Protocol Identifiers July 1997
802-1Q PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"IEEE 802.1Q VLAN Encapsulation header.
Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR-
encap bit) is identified in protocolDirID strings utilizing this
PI macro.
[Ed. - Note that an official EtherType value has not yet been
assigned for the TagType field in the TPID portion of the VLAN
header. Therefore, the string 'PQ' refers to the MSB of the
EtherType, and the string 'RS' refers the the LSB of the
EtherType value. These strings will be replaced with the actual
numeric constants before final publication.]"
CHILDREN
"The first byte of the 4-byte child identifier is used to
distinguish the particular base encoding that follows the 802.1Q
header. The remaining three bytes are used exactly as defined by
the indicated base layer encoding.
In order to simplify the child encoding for the most common
cases, the 'ether2' and 'snap' base layers are combined into a
single identifier, with a value of zero. The other baser layers
are encoded with values taken from Table 4.2.
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
Bierman/Bucci/Iddon Expires January, 1998 [Page 33]
Draft RMON Protocol Identifiers July 1997
The generic child layer-identifier format is shown below:
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.PQ.RS ], the protocol identifier
for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the MSB and LSB of the Ethernet-
II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.PQ.RS.0.0.8.0
defines IP, VLAN-encapsulated in ether2.
Children of this format are named as '802-1Q' followed by the
type field value in hexadecimal. The above example would be
declared as:
'802-1Q 0x0800'.
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.PQ.RS ], the protocol identifier
component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the
SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.PQ.RS.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
Bierman/Bucci/Iddon Expires January, 1998 [Page 34]
Draft RMON Protocol Identifiers July 1997
Children are named as '802-1Q_llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
'802-1Q_llc 0xf0'
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.PQ.RS ], the protocol identifier
for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are
the 3 octets of the OUI field in network byte order.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.PQ.RS.4.8.0.7 defines the Apple-specific set of
protocols, VLAN-encapsulated over vsnap.
Children are named as '802-1Q_vsnap <OUI>', where the '<OUI>'
field is represented as 3 octets in hexadecimal notation.
So the above example would be named:
'802-1Q_vsnap 0x080007'.
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.PQ.RS ], the protocol identifier
for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the
network byte order encodings of the MSB and LSB of the
enumeration value for the particular IANA assigned protocol.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.PQ.RS.5.0.0.0.1
defines the IPX protocol, VLAN-encapsulated directly in 802.3
Children are named '802-1Q_iana' followed by the numeric value of
the particular IANA assigned protocol. The above example would be
named:
'802-1Q_iana 1'. "
Bierman/Bucci/Iddon Expires January, 1998 [Page 35]
Draft RMON Protocol Identifiers July 1997
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0xPQRS -- Ethernet or SNAP encoding of TPID
-- PQRS == EtherType not yet assigned
-- snap 0xPQRS ** excluded to reduce PD size & complexity
}
5.4. Protocol Stacks And Single-Vendor Applications
Network layer protocol identifier macros contain additional information
about the network layer, and is found immediately following a base
layer-identifier in a protocol identifier.
The ProtocolDirParameters supported at the network layer are
'countsFragments(0)', and 'tracksSessions(1). An agent may choose to
implement a subset of these parameters.
The protocol-name should be used for the ProtocolDirDescr field. The
ProtocolDirType ATTRIBUTES used at the network layer are
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose
to implement a subset of these attributes for each protocol, and
therefore limit which tables the indicated protocol can be present (e.g.
protocol distribution, host, and matrix tables)..
The following protocol-identifier macro declarations are given for
example purposes only. They are not intended to constitute an exhaustive
list or an authoritative source for any of the protocol information
given. However, any protocol that can encapsulate other protocols must
be documented here in order to encode the children identifiers into
protocolDirID strings. Leaf protocols should be documented as well, but
an implementation can identify a leaf protocol even if it isn't listed
here (as long as the parent is documented).
5.4.1. The TCP/IP protocol stack
chaosnet PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 36]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Chaosnet"
REFERENCE
"TBD"
::= {
ether2 0x804, -- [ 0.0.8.4 ]
802-1Q 0x804 -- [ 0.0.8.4 ]
}
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,
802-1Q 0x806 -- [ 0.0.8.6 ]
}
ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0) -- This parameter applies to all child
-- protocols.
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of 'ip' are selected by the value in the Protocol field
(one octet), as defined in the PROTOCOL NUMBERS table within the
Assigned Numbers Document.
The value of the Protocol field is encoded in an octet string as
Bierman/Bucci/Iddon Expires January, 1998 [Page 37]
Draft RMON Protocol Identifiers July 1997
[ 0.0.0.a ], where 'a' is the protocol field .
Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2.ip.ipip4.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip4.udp =
16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 791 [RFC791] defines the Internet Protocol; The following
URL defines the authoritative repository for the PROTOCOL NUMBERS
Table:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
ip 4, -- also represented by the ipip4 macro
ip 94, -- also represented by the ipip macro
802-1Q 0x0800, -- [0.0.8.0]
802-1Q_llc 0x06 -- [2.0.0.6]
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 38]
Draft RMON Protocol Identifiers July 1997
-- ****************************************************************
--
-- Children of IP
--
-- ****************************************************************
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol"
REFERENCE
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= {
ip 1,
ipip4 1,
ipip 1
}
igmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Group Management Protocol; IGMP is used by IP hosts to
report their host group memberships to any immediately-
neighboring multicast routers."
REFERENCE
"Appendix A of Host Extensions for IP Multicasting [RFC1112]
defines the Internet Group Management Protocol."
::= {
ip 2,
ipip4 2,
ipip 2
}
ggp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Gateway-to-Gateway Protocol; DARPA Internet Gateway
(historical)"
REFERENCE
"RFC 823 [RFC823] defines the Gateway-to-Gateway Protocol."
::= {
ip 3,
Bierman/Bucci/Iddon Expires January, 1998 [Page 39]
Draft RMON Protocol Identifiers July 1997
ipip4 3,
ipip 3
}
ipip4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"IP in IP Tunneling"
CHILDREN
"Children of 'ipip4' are selected and encoded in the same manner
as children of IP.
ADDRESS-FORMAT
"The 'ipip4' address format is the same as the IP address
format."
DECODING
"Note: ether2.ip.ipip4.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip4.udp =
16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 1853 [RFC1853] defines IP in IP over Protocol 4.;
RFC 2003 [RFC2003] defines IP Encapsulation within IP"
::= {
ip 4,
ipip4 4,
ipip 4
}
st PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Stream Protocol Version 2 (ST2); ST2 is an experimental
resource reservation protocol intended to provide end-to-end
real-time guarantees over an internet."
REFERENCE
"RFC 1819 [RFC1819] defines version 2 of the Internet Stream
Bierman/Bucci/Iddon Expires January, 1998 [Page 40]
Draft RMON Protocol Identifiers July 1997
Protocol."
::= {
ip 5,
ipip4 5,
ipip 5
}
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol"
CHILDREN
"Children of TCP are identified by the 16 bit Source or
Destination Port 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
port value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793 [RFC793] defines the Transmission 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"
::= {
ip 6,
ipip4 6,
ipip 6
}
ucl PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"UCL; University College London Protocol"
REFERENCE
"TBD"
::= {
Bierman/Bucci/Iddon Expires January, 1998 [Page 41]
Draft RMON Protocol Identifiers July 1997
ip 7,
ipip4 7,
ipip 7
}
egp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Exterior Gateway Protocol (historical)"
REFERENCE
"RFC 904 [RFC904] defines the Exterior Gateway Protocol."
::= {
ip 8,
ipip4 8,
ipip 8
}
igp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Any private interior gateway."
REFERENCE
"TBD"
::= {
ip 9,
ipip4 9,
ipip 9
}
bbn-rcc-mon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BBN-RCC-MON; BBN RCC Monitoring Protocol"
REFERENCE
"TBD"
::= {
ip 10,
ipip4 10,
ipip 10
}
nvp2 PROTOCOL-IDENTIFIER
Bierman/Bucci/Iddon Expires January, 1998 [Page 42]
Draft RMON Protocol Identifiers July 1997
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NVP-II; Network Voice Protocol"
REFERENCE
"RFC 741 [RFC741] defines the Network Voice Protocol"
::= {
ip 11,
ipip4 11,
ipip 11
}
pup PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"PUP Protocol"
REFERENCE
"Xerox; TBD"
::= {
ip 12,
ipip4 12,
ipip 12
}
argus PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ARGUS Protocol"
REFERENCE
"TBD"
::= {
ip 13,
ipip4 13,
ipip 13
}
emcon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Emission Control Protocol"
REFERENCE
"TBD"
Bierman/Bucci/Iddon Expires January, 1998 [Page 43]
Draft RMON Protocol Identifiers July 1997
::= {
ip 14,
ipip4 14,
ipip 14
}
xnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Cross Net Debugger (historical)"
REFERENCE
"[IEN158]"
::= {
ip 15,
ipip4 15,
ipip 15
}
chaos PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CHAOS Protocol"
REFERENCE
"TBD"
::= {
ip 16,
ipip4 16,
ipip 16
}
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol"
CHILDREN
"Children of UDP are identified by the 16 bit Source or
Destination Port 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
port value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
Bierman/Bucci/Iddon Expires January, 1998 [Page 44]
Draft RMON Protocol Identifiers July 1997
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768 [RFC768] defines the User Datagram Protocol.
The following URL defines the authoritative repository for
reserved and registered UDP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= {
ip 17,
ipip4 17,
ipip 17
}
mux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Multiplexing Protocol (historical)"
REFERENCE
"IEN-90 [IEN-90] defines the Multiplexing Protocol"
::= {
ip 18,
ipip4 18,
ipip 18
}
dcn-meas PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DCN Measurement Subsystems"
REFERENCE
"TBD"
::= {
ip 19,
ipip4 19,
ipip 19
}
hmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 45]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"Host Monitoring Protocol"
REFERENCE
"RFC 869 [RFC869] defines the Host Monitoring Protocol"
::= {
ip 20,
ipip4 20,
ipip 20
}
prm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Packet Radio Measurement"
REFERENCE
"TBD"
::= {
ip 21,
ipip4 21,
ipip 21
}
xns-idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XEROX NS IDP"
REFERENCE
"TBD"
::= {
ip 22,
ipip4 22,
ipip 22
}
trunk-1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Trunk-1 Protocol"
REFERENCE
"TBD"
::= {
ip 23,
Bierman/Bucci/Iddon Expires January, 1998 [Page 46]
Draft RMON Protocol Identifiers July 1997
ipip4 23,
ipip 23
}
trunk-2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Trunk-2 Protocol"
REFERENCE
"TBD"
::= {
ip 24,
ipip4 24,
ipip 24
}
leaf-1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Leaf-1 Protocol"
REFERENCE
"TBD"
::= {
ip 25,
ipip4 25,
ipip 25
}
leaf-2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Leaf-2 Protocol"
REFERENCE
"TBD"
::= {
ip 26,
ipip4 26,
ipip 26
}
rdp PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 47]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Reliable Data Protocol"
REFERENCE
"RFC 908 [RFC908] defines the original protocol; RFC 1151
[RFC1151] defines version 2 of the Reliable Data Protocol."
::= {
ip 27,
ipip4 27,
ipip 27
}
irtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Reliable Transaction Protocol"
REFERENCE
"RFC 938 [RFC938] defines the Internet Reliable Transaction
Protocol functional and interface specification."
::= {
ip 28,
ipip4 28,
ipip 28
}
iso-tp4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO Transport Protocol Specification"
REFERENCE
"RFC 905 [RFC905] defines the ISO Transport Protocol
Specification; ISO DP 8073"
::= {
ip 29,
ipip4 29,
ipip 29
}
netblt PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bulk Data Transfer Protocol"
Bierman/Bucci/Iddon Expires January, 1998 [Page 48]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"RFC 998 [RFC998] defines NETBLT: A Bulk Data Transfer Protocol."
::= {
ip 30,
ipip4 30,
ipip 30
}
mfe-nsp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MFE Network Services Protocol"
REFERENCE
"TBD"
::= {
ip 31,
ipip4 31,
ipip 31
}
merit-inp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MERIT Internodal Protocol"
REFERENCE
"TBD"
::= {
ip 32,
ipip4 32,
ipip 32
}
sep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Sequential Exchange Protocol"
REFERENCE
"TBD"
::= {
ip 33,
ipip4 33,
ipip 33
Bierman/Bucci/Iddon Expires January, 1998 [Page 49]
Draft RMON Protocol Identifiers July 1997
}
third-pc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"3PC; Third Party Connect Protocol"
REFERENCE
"TBD"
::= {
ip 34,
ipip4 34,
ipip 34
}
idpr PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Inter-Domain Policy Routing Protocol"
REFERENCE
"RFC 1479 [RFC1479] defines Version 1 of the Inter-Domain Policy
Routing Protocol."
::= {
ip 35,
ipip4 35,
ipip 35
}
xtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XTP"
REFERENCE
"TBD"
::= {
ip 36,
ipip4 36,
ipip 36
}
ddp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 50]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"Datagram Delivery Protocol"
REFERENCE
"TBD"
::= {
ip 37,
ipip4 37,
ipip 37
}
idpr-cmtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IDPR Control Message Transport Protocol"
REFERENCE
"RFC 1479 [RFC1479] defines Version 1 of the Inter-Domain Policy
Routing Protocol."
::= {
ip 38,
ipip4 38,
ipip 38
}
tp-plus-plus PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TP++ Transport Protocol"
REFERENCE
"TBD"
::= {
ip 39,
ipip4 39,
ipip 39
}
il PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IL Transport Protocol"
REFERENCE
"TBD"
::= {
Bierman/Bucci/Iddon Expires January, 1998 [Page 51]
Draft RMON Protocol Identifiers July 1997
ip 40,
ipip4 40,
ipip 40
}
sip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Internet Protocol"
REFERENCE
"TBD"
::= {
ip 41,
ipip4 41,
ipip 41
}
sdrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Source Demand Routing Protocol"
REFERENCE
"RFC 1940 [RFC1940] defines version 1 of the Source Demand
Routing: Packet Format and Forwarding Specification"
::= {
ip 42,
ipip4 42,
ipip 42
}
sip-sr PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SIP Source Route"
REFERENCE
"TBD"
::= {
ip 43,
ipip4 43,
ipip 43
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 52]
Draft RMON Protocol Identifiers July 1997
sip-frag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SIP Fragment"
REFERENCE
"TBD"
::= {
ip 44,
ipip4 44,
ipip 44
}
idrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Inter-Domain Routing Protocol"
REFERENCE
"RFC 1745 [RFC1745] defines BGP4/IDRP for IP."
::= {
ip 45,
ipip4 45,
ipip 45
}
rsvp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Resource Reservation Setup Protocol"
REFERENCE
"TBD"
::= {
ip 46,
ipip4 46,
ipip 46
}
gre PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"General Routing Encapsulation"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 53]
Draft RMON Protocol Identifiers July 1997
"RFC 1701 [RFC1701] defines Generic Routing Encapsulation (GRE);
RFC 1702 [RFC1702] defines Generic Routing Encapsulation over
IPv4 networks"
::= {
ip 47,
ipip4 47,
ipip 47
}
mhrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Mobile Host Routing Protocol"
REFERENCE
"TBD"
::= {
ip 48,
ipip4 48,
ipip 48
}
bna PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BNA"
REFERENCE
"TBD"
::= {
ip 49,
ipip4 49,
ipip 49
}
sipp-esp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SIPP Encap Security Payload"
REFERENCE
"TBD"
::= {
ip 50,
ipip4 50,
Bierman/Bucci/Iddon Expires January, 1998 [Page 54]
Draft RMON Protocol Identifiers July 1997
ipip 50
}
sipp-ah PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SIPP Authentication Header"
REFERENCE
"TBD"
::= {
ip 51,
ipip4 51,
ipip 51
}
i-nlsp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Integrated Net Layer Security TUBA"
REFERENCE
"TBD"
::= {
ip 52,
ipip4 52,
ipip 52
}
swipe PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IP with Encryption"
REFERENCE
"TBD"
::= {
ip 53,
ipip4 53,
ipip 53
}
nhrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 55]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"NBMA Next Hop Resolution Protocol"
REFERENCE
"TBD"
::= {
ip 54,
ipip4 54,
ipip 54
}
-- 55-60 Unassigned
priv-host PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any internal host protocol."
REFERENCE
"N/A"
::= {
ip 61,
ipip4 61,
ipip 61
}
cftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CFTP"
REFERENCE
"TBD"
::= {
ip 62,
ipip4 62,
ipip 62
}
priv-net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any local network protocol."
REFERENCE
"N/A"
Bierman/Bucci/Iddon Expires January, 1998 [Page 56]
Draft RMON Protocol Identifiers July 1997
::= {
ip 63,
ipip4 63,
ipip 63
}
sat-expak PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SATNET and Backroom EXPAK"
REFERENCE
"TBD"
::= {
ip 64,
ipip4 64,
ipip 64
}
kryptolan PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Kryptolan"
REFERENCE
"TBD"
::= {
ip 65,
ipip4 65,
ipip 65
}
rvd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MIT Remote Virtual Disk Protocol"
REFERENCE
"TBD"
::= {
ip 66,
ipip4 66,
ipip 66
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 57]
Draft RMON Protocol Identifiers July 1997
ippc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Pluribus Packet Core"
REFERENCE
"TBD"
::= {
ip 67,
ipip4 67,
ipip 67
}
priv-distfile PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any distributed file system."
REFERENCE
"N/A"
::= {
ip 68,
ipip4 68,
ipip 68
}
sat-mon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SATNET Monitoring"
REFERENCE
"TBD"
::= {
ip 69,
ipip4 69,
ipip 69
}
visa PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"VISA Protocol"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 58]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= {
ip 70,
ipip4 70,
ipip 70
}
ipcv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Packet Core Utility"
REFERENCE
"TBD"
::= {
ip 71,
ipip4 71,
ipip 71
}
cpnx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Computer Protocol Network Executive"
REFERENCE
"TBD"
::= {
ip 72,
ipip4 72,
ipip 72
}
cphb PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Computer Protocol Heart Beat"
REFERENCE
"TBD"
::= {
ip 73,
ipip4 73,
ipip 73
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 59]
Draft RMON Protocol Identifiers July 1997
wsn PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Wang Span Network"
REFERENCE
"TBD"
::= {
ip 74,
ipip4 74,
ipip 74
}
pvp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Packet Video Protocol"
REFERENCE
"TBD"
::= {
ip 75,
ipip4 75,
ipip 75
}
br-sat-mon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Backroom SATNET Monitoring"
REFERENCE
"TBD"
::= {
ip 76,
ipip4 76,
ipip 76
}
sun-nd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SUN ND PROTOCOL-Temporary"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 60]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= {
ip 77,
ipip4 77,
ipip 77
}
wb-mon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"WIDEBAND Monitoring"
REFERENCE
"TBD"
::= {
ip 78,
ipip4 78,
ipip 78
}
wb-expak PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"WIDEBAND EXPAK"
REFERENCE
"TBD"
::= {
ip 79,
ipip4 79,
ipip 79
}
ISO-IP PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO Internet Protocol"
REFERENCE
"TBD"
::= {
ip 80,
ipip4 80,
ipip 80
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 61]
Draft RMON Protocol Identifiers July 1997
vmtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Versatile Message Transaction Protocol"
REFERENCE
"TBD"
::= {
ip 81,
ipip4 81,
ipip 81
}
secure-mvtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Secure Versatile Message Transaction Protocol"
REFERENCE
"TBD"
::= {
ip 82,
ipip4 82,
ipip 82
}
vines PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"VINES"
REFERENCE
"TBD"
::= {
ip 83,
ipip4 83,
ipip 83
}
ttp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TTP"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 62]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= {
ip 84,
ipip4 84,
ipip 84
}
nfsnet-igp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NSFNET-IGP"
REFERENCE
"TBD"
::= {
ip 85,
ipip4 85,
ipip 85
}
dgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Dissimilar Gateway Protocol"
REFERENCE
"TBD"
::= {
ip 86,
ipip4 86,
ipip 86
}
tcf PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TCF"
REFERENCE
"TBD"
::= {
ip 87,
ipip4 87,
ipip 87
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 63]
Draft RMON Protocol Identifiers July 1997
igrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IGRP; Cisco routing protocol"
REFERENCE
"TBD"
::= {
ip 88,
ipip4 88,
ipip 88
}
ospf PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Open Shortest Path First Interior GW Protocol (OSPFIGP)."
REFERENCE
"RFC 1583 [RFC1583] defines version 2 of the OSPF protocol."
::= {
ip 89,
ipip4 89,
ipip 89
}
sprite-rpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Sprite RPC Protocol"
REFERENCE
"TBD"
::= {
ip 90,
ipip4 90,
ipip 90
}
larp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Locus Address Resolution Protocol"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 64]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= {
ip 91,
ipip4 91,
ipip 91
}
mtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Multicast Transport Protocol"
REFERENCE
"RFC 1301 [RFC1301] defines the Multicast Transport Protocol."
::= {
ip 92,
ipip4 92,
ipip 92
}
ax-25 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AX.25 Frame Encapsulation"
REFERENCE
"RFC 1226 [RFC1226] defines Internet Protocol Encapsulation of
AX.25 Frames."
::= {
ip 93,
ipip4 93,
ipip 93
}
ipip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"IP-within-IP Encapsulation Protocol"
CHILDREN
"Children of 'ipip' are selected and encoded in the same manner
as children of IP.
Bierman/Bucci/Iddon Expires January, 1998 [Page 65]
Draft RMON Protocol Identifiers July 1997
ADDRESS-FORMAT
"The 'ipip' address format is the same as the IP address format."
DECODING
"Note: ether2.ip.ipip.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip.udp =
16.0.0.0.1.0.0.8.0.0.0.0.94.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"TBD"
::= {
ip 94,
ipip4 94,
ipip 94
}
micp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Mobile Internetworking Control Protocol"
REFERENCE
"TBD"
::= {
ip 95,
ipip4 95,
ipip 95
}
scc-sp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Semaphore Communications Sec. Protocol"
REFERENCE
"TBD"
::= {
ip 96,
ipip4 96,
ipip 96
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 66]
Draft RMON Protocol Identifiers July 1997
etherip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Ethernet-within-IP Encapsulation"
REFERENCE
"TBD"
::= {
ip 97,
ipip4 97,
ipip 97
}
encap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Encapsulation Header; A Scheme for an Internet Encapsulation
Protocol: Version 1"
REFERENCE
"RFC 1241 [RFC1241] defines version 1 of the ENCAP Protocol."
::= {
ip 98,
ipip4 98,
ipip 98
}
priv-encript PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private encryption scheme."
REFERENCE
"N/A"
::= {
ip 99,
ipip4 99,
ipip 99
}
gmtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"GMTP"
Bierman/Bucci/Iddon Expires January, 1998 [Page 67]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"TBD"
::= {
ip 100,
ipip4 100,
ipip 100
}
-- 101-254 Unassigned
-- 255 Reserved
Bierman/Bucci/Iddon Expires January, 1998 [Page 68]
Draft RMON Protocol Identifiers July 1997
-- ****************************************************************
--
-- Children of UDP and TCP
--
-- ****************************************************************
tcpmux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TCP Port Service Multiplexer Port."
REFERENCE
"RFC 1078 [RFC1078] defines the TCP Port Service Multiplexer
Protocol."
::= { tcp 1 }
compressnet-mgmt PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Compression Management Utility."
REFERENCE
"TBD"
::= { tcp 2 }
compressnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Compression Process."
REFERENCE
"TBD"
::= { tcp 3 }
-- 4/tcp Unassigned
-- 4/udp Unassigned
rje PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Entry Protocol; RJE Logger Port; (historical)."
REFERENCE
"RFC 407 [RFC407] defines the Remote Job Entry Protocol."
::= { tcp 5 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 69]
Draft RMON Protocol Identifiers July 1997
-- 6/tcp Unassigned
-- 6/udp Unassigned
echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Echo Protocol for debugging TCP and UDP transports."
REFERENCE
"RFC 862 [RFC862] defines the Echo Protocol."
::= {
tcp 7,
udp 7 }
-- 8/tcp Unassigned
-- 8/udp Unassigned
discard PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Discard Protocol for debugging TCP and UDP transports."
REFERENCE
"RFC 863 [RFC863] defines the Discard Protocol."
::= {
tcp 9,
udp 9 }
-- 10/tcp Unassigned
-- 10/udp Unassigned
systat PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Retrieve the Active Users list; a debugging tool for TCP and UDP
transports."
REFERENCE
"RFC 866 [RFC866] defines the Active Users Protocol."
::= {
tcp 11,
udp 11 }
-- 12/tcp Unassigned
-- 12/udp Unassigned
Bierman/Bucci/Iddon Expires January, 1998 [Page 70]
Draft RMON Protocol Identifiers July 1997
daytime PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Retrieve the current time of day; a debugging tool for TCP and
UDP transports."
REFERENCE
"RFC 867 [RFC867] defines the Daytime Protocol."
::= {
tcp 13,
udp 13 }
-- 14/tcp Unassigned
-- 14/udp Unassigned
-- 15/tcp Unassigned [was netstat]
-- 15/udp Unassigned
-- 16/tcp Unassigned
-- 16/udp Unassigned
qotd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Quote of the Day Protocol; retrieve a short message (up to 512
bytes); a debugging tool for TCP and UDP transports."
REFERENCE
"RFC 865 [RFC865] defines the Quote of the Day Protocol."
::= {
tcp 17,
udp 17 }
msp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Message Send Protocol"
REFERENCE
"RFC 1312 [RFC1312] defines the Message Send Protocol."
::= {
tcp 18,
udp 18 }
chargen PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 71]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"Character Generator Protocol; a debugging tool for TCP and UDP
transports."
REFERENCE
"RFC 864 [RFC864] defines the Character Generator Protocol."
::= {
tcp 19,
udp 19 }
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Control Port; An FTP client initiates
an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }
-- 22/tcp Unassigned
-- 22/udp Unassigned
telnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"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
"RFC 854 [RFC854] defines the basic Telnet Protocol."
Bierman/Bucci/Iddon Expires January, 1998 [Page 72]
Draft RMON Protocol Identifiers July 1997
::= { tcp 23 }
priv-mail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private mail system."
REFERENCE
"N/A"
::= { tcp 24,
udp 24 }
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."
::= { tcp 25 }
-- 26/tcp Unassigned
-- 26/udp Unassigned
nsw-fe PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NSW User System FE Port"
REFERENCE
"TBD"
::= { tcp 27,
udp 27 }
-- 28/tcp Unassigned
-- 28/udp Unassigned
msg-icp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MSG ICP"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 73]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= { tcp 29,
udp 29 }
-- 30/tcp Unassigned
-- 30/udp Unassigned
msg-auth PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MSG Authentication"
REFERENCE
"TBD"
::= { tcp 31,
udp 31 }
-- 32/tcp Unassigned
-- 32/udp Unassigned
dsp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Display Support Protocol"
REFERENCE
"TBD"
::= { tcp 33,
udp 33 }
-- 34/tcp Unassigned
-- 34/udp Unassigned
priv-print PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private printer server."
REFERENCE
"N/A"
::= { tcp 35,
udp 35 }
-- 36/tcp Unassigned
-- 36/udp Unassigned
Bierman/Bucci/Iddon Expires January, 1998 [Page 74]
Draft RMON Protocol Identifiers July 1997
time PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Time Protocol"
REFERENCE
"RFC 868 [RFC868] defines the Time Protocol."
::= { tcp 37,
udp 37 }
rap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Route Access Protocol"
REFERENCE
"RFC 1476 [RFC1476] defines the Internet Route Access Protocol."
::= { tcp 38 }
rlp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Resource Location Protocol"
REFERENCE
"RFC 887 [RFC887] defines the Resource Location Protocol."
::= { udp 39 }
-- 40/tcp Unassigned
-- 40/udp Unassigned
graphics PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Graphics Protocol"
REFERENCE
"RFC 493 [RFC493] defines the Graphics Protocol."
::= { tcp 41,
udp 41 }
nameserver PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
Bierman/Bucci/Iddon Expires January, 1998 [Page 75]
Draft RMON Protocol Identifiers July 1997
"Host Name Server Protocol"
REFERENCE
"IEN 116 [IEN116] defines the Internet Name Server."
::= { udp 42 }
nicname PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NICNAME/WHOIS Protocol"
REFERENCE
"RFC 954 [RFC954] defines the NICNAME/Who Is Protocol."
::= { tcp 43 }
mpm-flags PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MPM FLAGS Protocol; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 44 }
mpm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Message Processing Module -- Receiver; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 45 }
mpm-snd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Message Processing Module -- Default Send; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 46 }
ni-ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
Bierman/Bucci/Iddon Expires January, 1998 [Page 76]
Draft RMON Protocol Identifiers July 1997
"NI FTP"
REFERENCE
"TBD"
::= { tcp 47 }
auditd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Digital Audit Deamon"
REFERENCE
"TBD"
::= { tcp 48,
udp 48 }
tacacs PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Login Host Protocol (TACACS)"
REFERENCE
"TBD"
::= { tcp 49 }
re-mail-ck PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Mail Checking Protocol"
REFERENCE
"RFC 1339 [RFC1339] defines the Remote Mail Checking Protocol."
::= { udp 50 }
la-maint PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IMP Logical Address Maintenance Protocol"
REFERENCE
"TBD"
::= { udp 51 }
xns-time PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 77]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"XNS Time Protocol"
REFERENCE
"TBD"
::= { tcp 52,
udp 52 }
-- [ed. - also called 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 }
xns-ch PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Clearinghouse"
REFERENCE
"TBD"
::= { tcp 54,
udp 54 }
isi-gl PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISI Graphics Language"
REFERENCE
"TBD"
::= { tcp 55,
udp 55 }
xns-auth PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
Bierman/Bucci/Iddon Expires January, 1998 [Page 78]
Draft RMON Protocol Identifiers July 1997
"XNS Authentication Protocol"
REFERENCE
"TBD"
::= { tcp 56,
udp 56 }
priv-term PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private terminal access
protocol."
REFERENCE
"N/A"
::= { tcp 57,
udp 57 }
xns-mail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Mil Protocol"
REFERENCE
"TBD"
::= { tcp 58,
udp 58 }
priv-file PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private file service."
REFERENCE
"N/A"
::= { tcp 59,
udp 59 }
-- 60/tcp Unassigned
-- 60/udp Unassigned
ni-mail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NI MAIL"
Bierman/Bucci/Iddon Expires January, 1998 [Page 79]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"TBD"
::= { tcp 61,
udp 61 }
acas PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ACA Services; Digital's Corba Server"
REFERENCE
"TBD"
::= { tcp 62 }
-- 63/tcp Unassigned
-- 63/udp Unassigned
covia PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Communications Integrator (CI)."
REFERENCE
"TBD"
::= { tcp 64 }
tacacs-ds PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Default Server Port; TACACS Access Control Protocol Database
Service."
REFERENCE
"RFC 1492 [RFC1492] defines the TACACS Protocol."
::= { tcp 65 }
sql*net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Oracle SQL*NET"
REFERENCE
"TBD"
::= { tcp 66 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 80]
Draft RMON Protocol Identifiers July 1997
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 }
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 }
tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2);
RFC 1782 [RFC1782] defines TFTP Option Extensions;
RFC 1783 [RFC1783] defines the TFTP Blocksize Option;
RFC 1784 [RFC1784] defines TFTP Timeout Interval and Transfer Size
Options."
::= { udp 69 }
gopher PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Gopher Protocol"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 81]
Draft RMON Protocol Identifiers July 1997
"RFC 1436 [RFC1436] defines the Gopher Protocol."
::= { tcp 70 }
netrjs-1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 71 }
netrjs-2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 72 }
netrjs-3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 73 }
netrjs-4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 74 }
priv-dialout PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private dial out service."
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 82]
Draft RMON Protocol Identifiers July 1997
"N/A"
::= { tcp 75,
udp 75 }
deos PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Distributed External Object Store Protocol"
REFERENCE
"TBD"
::= { tcp 76,
udp 76 }
priv-rje PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private remote job entry
service."
REFERENCE
"N/A"
::= { tcp 77,
udp 77 }
vettcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"VET TCP"
REFERENCE
"TBD"
::= { tcp 78,
udp 78 }
finger PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Finger User Information Protocol"
REFERENCE
"RFC 1288 [RFC1288] defines the finger protocol."
::= { tcp 79 }
www-http PROTOCOL-IDENTIFIER
Bierman/Bucci/Iddon Expires January, 1998 [Page 83]
Draft RMON Protocol Identifiers July 1997
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol"
REFERENCE
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol (HTTP/1.0).
RFC 2068 [RFC2068] defines the Hypertext Transfer Protocol (HTTP/1.1).
RFC 2069 [RFC2069] defines an Extension to HTTP: Digest Access
Authentication.
RFC 2109 [RFC2109] defines the HTTP State Management Mechanism.
RFC 2145 [RFC2145] defines the use and interpretation of HTTP
version numbers."
::= { tcp 80 }
hosts2-ns PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"HOSTS2 Name Server"
REFERENCE
"TBD"
::= { tcp 81,
udp 81 }
xfer PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XFER Utility"
REFERENCE
"TBD"
::= { tcp 82,
udp 82 }
mit-ml-dev PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MIT ML Device"
REFERENCE
"TBD"
::= { tcp 83,
udp 83,
tcp 85,
udp 85 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 84]
Draft RMON Protocol Identifiers July 1997
ctf PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Common Trace Facility"
REFERENCE
"TBD"
::= { tcp 84,
udp 84 }
mfcobol PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Micro Focus Cobol"
REFERENCE
"TBD"
::= { tcp 86 }
priv-termlink PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private terminal link
protocol."
REFERENCE
"N/A"
::= { tcp 87,
udp 87 }
kerberos PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Kerberos Network Authentication Service (V5)"
REFERENCE
"RFC 1510 [RFC1510] defines the Kerberos protocol."
::= { udp 88 }
su-mit-tg PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SU/MIT Telnet Gateway Protocol"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 85]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= { tcp 89 }
dnsix PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DNSIX Security Attribute Token Map"
REFERENCE
"TBD"
::= { tcp 90 }
mit-dov PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MIT Dover Spooler"
REFERENCE
"TBD"
::= { tcp 91 }
npp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network Printing Protocol"
REFERENCE
"TBD"
::= { tcp 92,
udp 92 }
dcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Device Control Protocol"
REFERENCE
"TBD"
::= { tcp 93,
udp 93 }
objcall PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
Bierman/Bucci/Iddon Expires January, 1998 [Page 86]
Draft RMON Protocol Identifiers July 1997
"Tivoli Object Dispatcher"
REFERENCE
"TBD"
::= { tcp 94 }
supdup PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SUPDUP Display; (historical)"
REFERENCE
"RFC 734 [RFC734] defines the SUPDUP Protocol."
::= { tcp 95 }
dixie PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DIXIE Directory Service"
REFERENCE
"RFC 1249 [RFC1249] defines the DIXIE Protocol."
::= { tcp 96,
udp 96 }
swift-rvf PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Swift Remote Vitural File Protocol"
REFERENCE
"TBD"
::= { tcp 97,
udp 97 }
tacnews PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TAC News"
REFERENCE
"TBD"
::= { tcp 98,
udp 98 }
metagram PROTOCOL-IDENTIFIER
Bierman/Bucci/Iddon Expires January, 1998 [Page 87]
Draft RMON Protocol Identifiers July 1997
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Metagram Relay"
REFERENCE
"TBD"
::= { tcp 99,
udp 99 }
newacct PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unauthorized use of New Account Protocol."
REFERENCE
"TBD"
::= { tcp 100 }
hostname PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NIC Internet Hostname Server Protocol; (historical)"
REFERENCE
"RFC 953 [RFC953] defines the Hostname Server Protocol."
::= { tcp 101 }
iso-tsap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO-TSAP Class 0"
REFERENCE
"TBD"
::= { tcp 102,
udp 102 }
gppitnp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Genesis Point-to-Point Trans Net"
REFERENCE
"TBD"
::= { tcp 103,
Bierman/Bucci/Iddon Expires January, 1998 [Page 88]
Draft RMON Protocol Identifiers July 1997
udp 103 }
acr-nema PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ACR-NEMA Digital Imag. & Comm. 300"
REFERENCE
"TBD"
::= { tcp 104 }
csnet-ns PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Mailbox Name Nameserver"
REFERENCE
"TBD"
::= { tcp 105,
udp 105 }
3com-tsmux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"3COM-TSMUX"
REFERENCE
"TBD"
::= { tcp 106,
udp 106 }
rtelnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote User Telnet Protocol; (historical)."
REFERENCE
"RFC 818 [RFC818] defines the Remote User Telnet Service."
::= { tcp 107 }
snagas PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SNA Gateway Access Server"
Bierman/Bucci/Iddon Expires January, 1998 [Page 89]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"TBD"
::= { tcp 108 }
pop2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 2. Clients establish connections
with POP2 servers by using this destination port number."
REFERENCE
"RFC 937 [RFC937] defines Version 2 of the Post Office Protocol."
::= { tcp 109 }
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC 1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
::= { tcp 110,
udp 110 } -- RFC defines tcp use
sunrpc PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1) -- learn port mapping of programs
}
ATTRIBUTES {
hasChildren(0) -- port mapper function numbers
}
DESCRIPTION
"SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN
"Specific RPC functions are represented as children of the sunrpc
protocol. Each 'RPC function protocol' is identified by its
function number assignment. RPC function number assignments are
defined by different naming authorities, depending on the
function identifier value.
From [RFC1831]:
Program numbers are given out in groups of hexadecimal 20000000
Bierman/Bucci/Iddon Expires January, 1998 [Page 90]
Draft RMON Protocol Identifiers July 1997
(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'."
DECODING
"The first packet of many SUNRPC transactions is sent to the
port- mapper program, and therefore decoded statically by
monitoring RFC portmap requests [RFC1831]. Any subsequent packets
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]).
In some cases the port mapping for a particular protocol is well
known and hard coded into the requesting client. In these cases
the client will not send portmap requests; instead it will send
the SUNRPC request directly to the well known port. These cases
are rare and are being eliminated over time. NFS is the most
significant SUNRPC program of this class. Such programs should
still be declared as children of SUNRPC as described under
CHILDREN above. How an implementation detects this behaviour and
handles it is beyond the scope of this document.
The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
the probe can (and should) monitor portmapper activity to
correctly track SUNRPC connections."
Bierman/Bucci/Iddon Expires January, 1998 [Page 91]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
::= { tcp 111,
udp 111 }
mcidas PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"McIDAS Data Transmission Protocol"
REFERENCE
"TBD"
::= { tcp 112 }
auth PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Authentication Service; Identification Protocol."
REFERENCE
"RFC 1413 [RFC1413] defines the Identification Protocol."
::= { tcp 113 }
audionews PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Audio News Multicast"
REFERENCE
"TBD"
::= { tcp 114,
udp 114 }
sftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple File Transfer Protocol; (historical)."
REFERENCE
"RFC 913 [RFC913] defines the Simple File Transfer Protocol."
::= { tcp 115 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 92]
Draft RMON Protocol Identifiers July 1997
ansanotify PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ANSA REX Notify"
REFERENCE
"TBD"
::= { tcp 116,
udp 116 }
uucp-path PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"UUCP Path Service"
REFERENCE
"RFC 915 [RFC915] defines the Network Mail Path Service."
::= { tcp 117 }
sqlserv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SQL Services"
REFERENCE
"TBD"
::= { tcp 118,
udp 118 }
nntp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network News Transfer Protocol"
REFERENCE
"RFC 977 [RFC977] defines the Network News Transfer Protocol."
::= { tcp 119 }
cfdptkt PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CFDPTKT; Coherent File Distribution Protocol"
REFERENCE
"RFC 1235 [RFC1235] defines the Coherent File Distribution
Bierman/Bucci/Iddon Expires January, 1998 [Page 93]
Draft RMON Protocol Identifiers July 1997
Protocol."
::= { udp 120 }
erpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Encore Expedited Remote Pro.Call"
REFERENCE
"TBD"
::= { tcp 121,
udp 121 }
smakynet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SMAKYNET"
REFERENCE
"TBD"
::= { tcp 122,
udp 122 }
ntp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network Time Protocol"
REFERENCE
"RFC 1305 [RFC1305] defines version 3 of the Network Time
Protocol."
::= { udp 123 }
ansatrader PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ANSA REX Trader"
REFERENCE
"TBD"
::= { tcp 124,
udp 124 }
locus-map PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 94]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Locus PC-Interface Net Map Server"
REFERENCE
"TBD"
::= { tcp 125 }
unitary PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unisys Unitary Login"
REFERENCE
"TBD"
::= { tcp 126,
udp 126 }
locus-con PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Locus PC-Interface Conn Server"
REFERENCE
"TBD"
::= { tcp 127 }
gss-xlicen PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"X License Verification"
REFERENCE
"TBD"
::= { tcp 128,
udp 128 }
pwdgen PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Password Generator Protocol"
REFERENCE
"RFC 972 [RFC972] defines the Password Generator Protocol."
::= { tcp 129,
udp 129 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 95]
Draft RMON Protocol Identifiers July 1997
cisco-fna PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco FNATIVE"
REFERENCE
"TBD"
::= { tcp 130,
udp 130 }
cisco-tna PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco TNATIVE"
REFERENCE
"TBD"
::= { tcp 131,
udp 131 }
cisco-sys PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco SYSMAINT"
REFERENCE
"TBD"
::= { tcp 132,
udp 132 }
statsrv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Statistics Server; (historical)."
REFERENCE
"RFC 996 [RFC996] defines the Statistics Server Protocol."
::= { tcp 133,
udp 133 }
ingres-net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"INGRES-NET Service"
Bierman/Bucci/Iddon Expires January, 1998 [Page 96]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"TBD"
::= { tcp 134 }
loc-srv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Location Service"
REFERENCE
"TBD"
::= { tcp 135,
udp 135 }
profile PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"PROFILE Naming System"
REFERENCE
"TBD"
::= { tcp 136 }
-- defined as nbt-name in IPX section
-- netbios-ns 137/tcp NETBIOS Name Service
-- netbios-ns 137/udp NETBIOS Name Service
-- defined as nbt-data in IPX section
-- netbios-dgm 138/tcp NETBIOS Datagram Service
-- netbios-dgm 138/udp NETBIOS Datagram Service
-- defined as nbt-session in IPX section
-- netbios-ssn 139/tcp NETBIOS Session Service
-- netbios-ssn 139/udp NETBIOS Session Service
emfis-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"EMFIS Data Service"
REFERENCE
"TBD"
::= { tcp 140,
udp 140 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 97]
Draft RMON Protocol Identifiers July 1997
emfis-cntl PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"EMFIS Control Service"
REFERENCE
"TBD"
::= { tcp 141,
udp 141 }
bl-idm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Britton-Lee IDM"
REFERENCE
"TBD"
::= { tcp 142,
udp 142 }
imap2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Interactive Mail Access Protocol v2;
Internet Message Access Protocol v4 (IMAP4) also uses this
server port."
REFERENCE
"RFC 1064 [RFC1064] defines Version 2 of the Interactive Mail
Access
Protocol.
RFC 1730 [RFC1730] defines Version 4 of the Internet Message
Access
Protocol."
::= { tcp 143 }
news PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NewS"
REFERENCE
"TBD"
::= { tcp 144,
udp 144 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 98]
Draft RMON Protocol Identifiers July 1997
uaac PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"UAAC Protocol"
REFERENCE
"TBD"
::= { tcp 145,
udp 145 }
iso-tp0 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO-IP0; ISO-TP0 bridge between TCP and X.25"
REFERENCE
"RFC 1086 [RFC1086] defines the ISO-TP0 protocol."
::= { tcp 146,
udp 146 }
iso-ip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO-IP; Use of the Internet as a Subnetwork for Experimentation
with the OSI Network Layer"
REFERENCE
"RFC 1070 [RFC1070] defines the ISO-IP Protocol."
::= { tcp 147,
udp 147 }
cronus PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CRONUS-SUPPORT"
REFERENCE
"TBD"
::= { tcp 148,
udp 148 }
aed-512 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
Bierman/Bucci/Iddon Expires January, 1998 [Page 99]
Draft RMON Protocol Identifiers July 1997
"AED 512 Emulation Service"
REFERENCE
"TBD"
::= { tcp 149,
udp 149 }
sql-net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SQL-NET"
REFERENCE
"TBD"
::= { tcp 150,
udp 150 }
hems PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"HEMS; High Level Entity Management System; (historical)."
REFERENCE
"RFC 1021 [RFC1021] defines HEMS."
::= { tcp 151 }
bftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Background File Transfer Program"
REFERENCE
"RFC 1068 [RFC1068] defines the Background File Transfer
Program."
::= { tcp 152 }
sgmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Gateway Monitoring Protocol; (historical)."
REFERENCE
"RFC 1028 [RFC1028] defines the Simple Gateway Monitoring
Protocol."
::= { udp 153 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 100]
Draft RMON Protocol Identifiers July 1997
netsc-prod PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NETSC"
REFERENCE
"TBD"
::= { tcp 154,
udp 154 }
netsc-dev PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NETSC"
REFERENCE
"TBD"
::= { tcp 155,
udp 155 }
sqlsrv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SQL Services; protocol to talk to Oracle databases;
(historical)."
REFERENCE
"TBD"
::= { tcp 156 }
knet-cmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"KNET/VM Command/Message Protocol"
REFERENCE
"TBD"
::= { tcp 157 }
pcmail-srv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"PCMail Server; Distributed Mail System Protocol (DMSP)"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 101]
Draft RMON Protocol Identifiers July 1997
"RFC 1056 [RFC1056] defines the PCMAIL Protocol."
::= { tcp 158 }
nss-routing PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NSS-Routing"
REFERENCE
"TBD"
::= { tcp 159,
udp 159 }
sgmp-traps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Gateway Monitoring Protocol Traps; (historical)."
REFERENCE
"RFC 1028 [RFC1028] defines the Simple Gateway Monitoring
Protocol."
::= { udp 160 }
-- snmp and snmptrap found in the Protocol-Independent section
-- snmp 161/udp SNMP
-- snmptrap 162/udp SNMPTRAP
cmip-man PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CMIP/TCP (CMOT) Manager; (historical)."
REFERENCE
"RFC 1095 [RFC1095] defines the Common Management Information
Services and Protocol over TCP/IP."
::= { tcp 163,
udp 163 }
cmip-agent PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CMIP/TCP (CMOT) Agent; (historical)."
REFERENCE
"RFC 1095 [RFC1095] defines the Common Management Information
Bierman/Bucci/Iddon Expires January, 1998 [Page 102]
Draft RMON Protocol Identifiers July 1997
Services and Protocol over TCP/IP."
::= { tcp 164,
udp 164 }
xns-courier PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Xerox [TBD]"
REFERENCE
"TBD"
::= { tcp 165,
udp 165 }
s-net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Sirius Systems"
REFERENCE
"TBD"
::= { tcp 166,
udp 166 }
namp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NAMP"
REFERENCE
"TBD"
::= { tcp 167,
udp 167 }
rsvd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"RSVD"
REFERENCE
"TBD"
::= { tcp 168,
udp 168 }
send PROTOCOL-IDENTIFIER
Bierman/Bucci/Iddon Expires January, 1998 [Page 103]
Draft RMON Protocol Identifiers July 1997
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SEND"
REFERENCE
"TBD"
::= { tcp 169,
udp 169 }
print-srv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network PostScript"
REFERENCE
"TBD"
::= { tcp 170,
udp 170 }
multiplex PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network Innovations Multiplex"
REFERENCE
"TBD"
::= { tcp 171,
udp 171 }
cl-1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network Innovations CL/1"
REFERENCE
"TBD"
::= { tcp 172,
udp 172 }
xyplex-mux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Xyplex"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 104]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= { tcp 173,
udp 173 }
mailq PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MAILQ"
REFERENCE
"TBD"
::= { tcp 174,
udp 174 }
vmnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"VMNET"
REFERENCE
"TBD"
::= { tcp 175,
udp 175 }
genrad-mux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"GENRAD-MUX"
REFERENCE
"TBD"
::= { tcp 176,
udp 176 }
xdmcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"X Display Manager Control Protocol"
REFERENCE
"TBD"
::= { udp 177 }
nextstep PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 105]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"NextStep Window Server"
REFERENCE
"TBD"
::= { tcp 178,
udp 178 }
bgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Border Gateway Protocol"
REFERENCE
"RFC 1267 [RFC1267] defines version 3 of the Border Gateway
Protocol."
::= { tcp 179 }
ris PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Intergraph"
REFERENCE
"TBD"
::= { tcp 180,
udp 180 }
unify PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unify [TBD]"
REFERENCE
"TBD"
::= { tcp 181,
udp 181 }
audit PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unisys Audit SITP"
REFERENCE
"TBD"
Bierman/Bucci/Iddon Expires January, 1998 [Page 106]
Draft RMON Protocol Identifiers July 1997
::= { tcp 182,
udp 182 }
ocbinder PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"OCBinder"
REFERENCE
"TBD"
::= { tcp 183,
udp 183 }
ocserver PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"OCServer"
REFERENCE
"TBD"
::= { tcp 184,
udp 184 }
remote-kis PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote-Knowbot Information Service (KIS)"
REFERENCE
"RFC 1739 [RFC1739] describes the KNOWBOT Protocol."
::= { tcp 185,
udp 185 }
kis PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Knowbot Information Service (KIS)"
REFERENCE
"RFC 1739 [RFC1739] describes the KNOWBOT Protocol."
::= { tcp 186,
udp 186 }
aci PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 107]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Application Communication Interface"
REFERENCE
"TBD"
::= { tcp 187,
udp 187 }
mumps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Plus Five's MUMPS"
REFERENCE
"TBD"
::= { tcp 188,
udp 188 }
qft PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Queued File Transport"
REFERENCE
"TBD"
::= { tcp 189 }
gacp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Gateway Access Control Protocol"
REFERENCE
"TBD"
::= { tcp 190,
udp 190 }
prospero PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Prospero Directory Service"
REFERENCE
"TBD"
::= { tcp 191 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 108]
Draft RMON Protocol Identifiers July 1997
osu-nms PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"OSU Network Monitoring System"
REFERENCE
"TBD"
::= { tcp 192,
udp 192 }
srmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Spider Remote Monitoring Protocol"
REFERENCE
"TBD"
::= { tcp 193,
udp 193 }
irc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Relay Chat Protocol"
REFERENCE
"RFC 1459 [RFC1459] defines the Internet Relay Chat Protocol."
::= { tcp 194,
udp 194 }
dn6-nlm-aud PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DNSIX Network Level Module Audit"
REFERENCE
"TBD"
::= { tcp 195 }
dn6-smm-red PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DNSIX Session Mgt Module Audit Redir"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 109]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= { tcp 196 }
dls PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Directory Location Service"
REFERENCE
"TBD"
::= { tcp 197,
udp 197 }
dls-mon PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Directory Location Service Monitor"
REFERENCE
"TBD"
::= { tcp 198,
udp 198 }
smux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SMUX; SNMP MUX Protocol and MIB; (historical)."
REFERENCE
"RFC 1227 [RFC1227] defines the SMUX Protocol."
::= { tcp 199 }
src PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IBM System Resource Controller"
REFERENCE
"TBD"
::= { tcp 200,
udp 200 }
--
-- AppleTalk applications are defined in the AppleTalk Stack section
--
Bierman/Bucci/Iddon Expires January, 1998 [Page 110]
Draft RMON Protocol Identifiers July 1997
-- at-rtmp 201/tcp AppleTalk Routing Maintenance
-- at-rtmp 201/udp AppleTalk Routing Maintenance
-- at-nbp 202/tcp AppleTalk Name Binding
-- at-nbp 202/udp AppleTalk Name Binding
-- at-3 203/tcp AppleTalk Unused
-- at-3 203/udp AppleTalk Unused
-- at-echo 204/tcp AppleTalk Echo
-- at-echo 204/udp AppleTalk Echo
-- at-5 205/tcp AppleTalk Unused
-- at-5 205/udp AppleTalk Unused
-- at-zis 206/tcp AppleTalk Zone Information
-- at-zis 206/udp AppleTalk Zone Information
-- at-7 207/tcp AppleTalk Unused
-- at-7 207/udp AppleTalk Unused
-- at-8 208/tcp AppleTalk Unused
-- at-8 208/udp AppleTalk Unused
tam PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Trivial Authenticated Mail Protocol"
REFERENCE
"TBD"
::= { tcp 209,
udp 209 }
z39-50 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ANSI Z39.50"
REFERENCE
"RFC 1729 [RFC1729] describes the Z39.50 Protocol."
::= { tcp 210 }
914c-g PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Texas Instruments 914C/G Terminal"
REFERENCE
"TBD"
::= { tcp 211,
udp 211 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 111]
Draft RMON Protocol Identifiers July 1997
anet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ATEXSSTR"
REFERENCE
"TBD"
::= { tcp 212,
udp 212 }
ipx-tunnel PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Tunneling IPX Traffic through IP Networks"
REFERENCE
"RFC 1234 [RFC1234] defines the IPX Tunnel Protocol."
::= { udp 213 }
vmpwscs PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"VM PWSCS"
REFERENCE
"TBD"
::= { tcp 214,
udp 214 }
softpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Insignia Solutions [TBD]"
REFERENCE
"TBD"
::= { tcp 215,
udp 215 }
atls PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Access Technology License Server"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 112]
Draft RMON Protocol Identifiers July 1997
"TBD"
::= { tcp 216,
udp 216 }
dbase PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"dBASE Unix"
REFERENCE
"TBD"
::= { tcp 217,
udp 217 }
mpp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Netix Message Posting Protocol"
REFERENCE
"RFC 1204 [RFC1204] defines the Message Posting Protocol."
::= { tcp 218 }
uarps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unisys ARPs"
REFERENCE
"TBD"
::= { tcp 219,
udp 219 }
imap3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Interactive Mail Access Protocol v3; (historical)."
REFERENCE
"RFC 1203 [RFC1203] defines version 3 of the Interactive Mail
Access Protocol."
::= { tcp 220 }
fln-spx PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 113]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Berkeley rlogind with SPX auth"
REFERENCE
"TBD"
::= { tcp 221,
udp 221 }
rsh-spx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Berkeley rshd with SPX auth"
REFERENCE
"TBD"
::= { tcp 222,
udp 222 }
cdc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Certificate Distribution Center"
REFERENCE
"TBD"
::= { tcp 223,
udp 223 }
-- 224-241 Reserved
-- 242/tcp Unassigned
-- 242/udp Unassigned
sur-meas PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Survey Measurement"
REFERENCE
"TBD"
::= { tcp 243,
udp 243 }
-- 244/tcp Unassigned
-- 244/udp Unassigned
Bierman/Bucci/Iddon Expires January, 1998 [Page 114]
Draft RMON Protocol Identifiers July 1997
link PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"LINK"
REFERENCE
"TBD"
::= { tcp 245,
udp 245 }
dsp3270 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Display Systems Protocol"
REFERENCE
"TBD"
::= { tcp 246,
udp 246 }
-- 247-255 Reserved
ldap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lightweight Directory Access Protocol"
REFERENCE
"RFC 1777 [RFC1777] defines Lightweight Directory Access
Protocol; RFC 1798 [RFC1798] defines Connection-less Lightweight
X.500 Directory Access Protocol"
::= { tcp 389, -- RFC 1777
udp 389 } -- RFC 1798
https PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Secure HTTP; HTTP over SSL"
REFERENCE
"Netscape; TBD"
::= { tcp 443 }
exec PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 115]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Remote Exec"
REFERENCE
"TBD"
::= { tcp 512 }
biff PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BIFF Protocol; used by system to notify users of new mail."
REFERENCE
"TBD"
::= { udp 512 }
login PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BSD Rlogin; remote login a la telnet"
REFERENCE
"RFC 1282 [RFC1282] defines the BSD Rlogin Protocol."
::= { tcp 513 }
who PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"rwho; show logged in users"
REFERENCE
"TBD"
::= { udp 513 }
cmd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"rcmd; rsh; Remote execution; like exec, but automatic"
REFERENCE
"TBD"
::= { tcp 514 }
syslog PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 116]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"syslog"
REFERENCE
"TBD"
::= { udp 514 }
printer PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Printer Spooler"
REFERENCE
"TBD"
::= { tcp 515 }
ip-xns-rip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS-RIP"
REFERENCE
"TBD"
::= { udp 520 }
uucp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unix-to-Unix copy protocol"
REFERENCE
"TBD"
::= { tcp 540 }
doom PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DOOM Game; Id Software"
REFERENCE
"TBD"
::= { tcp 666 }
--
-- Portmapper Functions; Children of sunrpc
Bierman/Bucci/Iddon Expires January, 1998 [Page 117]
Draft RMON Protocol Identifiers July 1997
--
portmapper PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SUNRPC PORTMAPPER program. This is the SUNRPC program which is
used to locate the UDP/TCP ports on which other SUNRPC programs
can be found."
REFERENCE
"Appendix A of RFC 1057 [RFC1057] describes the portmapper
operation."
::= { sunrpc 100000 }
nfs PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"NFS is a SUNRPC program which may or may not use the port mapper
SUNRPC program to connect clients and servers. In many cases the
NFS server program runs over UDP/TCP port 2049, but an
implementation is encouraged to perform further analysis before
assuming that a packet to/from this port is a SUNRPC/NFS packet.
Likewise an implementation is encouraged to track port mapper
activity to spot cases where it is used to locate the SUNRPC/NFS
program as this is more robust."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
xwin PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"X Windows Protocol"
DECODING
"The X Windows Protocol when run over UDP/TCP normally runs over
the well known port 6000. It can run over any port in the range
Bierman/Bucci/Iddon Expires January, 1998 [Page 118]
Draft RMON Protocol Identifiers July 1997
6000 to 6063, however. If the tracksSessions(1) parameter bit is
set the agent can and should detect such X Window sessions and
report them as the X protocol."
REFERENCE
"The X Windows Protocol is defined by TBD"
::= {
tcp 6000,
udp 6000
-- lat ?
}
5.4.2. Novell IPX Stack
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 8 bit packet type field. The
value is encoded into an octet string as [ 0.0.0.a ], where 'a'
is the single octet of the packet type field.
Notice that in many implementations of IPX usage of the packet
type field is inconsistent with the specification and
implementations are encouraged to use other techniques to map
inconsistent values to the correct value (which in these cases is
typically the Packet Exchange Protocol). It is beyond the scope
of this document to describe these techniques in more detail.
Children of IPX are encoded as [ 0.0.0.a ], and named as 'ipx a'
where a is the packet type value. The novell echo protocol is
referred to as 'ipx nov-echo' OR 'ipx 2'."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order."
REFERENCE
"The IPX protocol is defined by the Novell Corporation
A complete description of IPX may be secured at the following
address:
Bierman/Bucci/Iddon Expires January, 1998 [Page 119]
Draft RMON Protocol Identifiers July 1997
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, -- [ed. - [0.224.224.3] does not follow our
-- definition for children of LLC]
snap 0x8137, -- [0.0.129.55]
ianaAssigned 1, -- [0.0.0.1] (ipxOverRaw8023)
-- llc 224, [ed. - 0.0.0.224 not confirmed]
802-1Q 0x8137, -- [0.0.129.55]
802-1Q_iana 1 -- [5.0.0.1] (ipxOverRaw8023)
}
nov-rip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Routing Information Protocol"
REFERENCE
"[TBD]"
::= {
ipx 0x01, -- when reached by IPX packet type
nov-pep 0x0453, -- when reached by IPX socket number
ipx 0x0453
}
nov-echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Echo Protocol"
REFERENCE
"[TBD]"
::= { ipx 0x02 }
nov-error PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Error-handler Protocol"
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 120]
Draft RMON Protocol Identifiers July 1997
"[TBD]"
::= { ipx 0x03 }
nov-pep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell Packet Exchange Protocol. This is really a null protocol
layer as all IPX packets contain the relevant fields for this
protocol. This protocol is defined so that socket-based decoding
has a point of attachment in the decode tree while still allowing
packet type based decoding also."
CHILDREN
"Children of PEP are defined by the 16 bit socket values. 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 socket value.
Each IPX/PEP packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"[TBD]"
::= {
-- ipx 0x00 ** Many third party IPX's use this value always
ipx 0x04 -- Xerox assigned for PEP
-- ipx 0x11 ** Novell use this for PEP packets, often
}
nov-spx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell Sequenced Packet Exchange Protocol. This protocol is an
extension of IPX/PEP as it shares a common header."
CHILDREN
"Children of SPX are defined by the 16 bit socket values. 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 socket value.
Bierman/Bucci/Iddon Expires January, 1998 [Page 121]
Draft RMON Protocol Identifiers July 1997
Each IPX/SPX packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"[TBD]"
::= {
ipx 0x05 -- Xerox assigned for SPX
}
nlsp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NLSP [TBD]"
REFERENCE
"[TBD]"
::= { ipx 0x9001 } -- [ 0.0.144.1 ]
nov-sap PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell Service Advertising Protocol. This protocol binds
applications on a particular host to an IPX/PEP or IPX/SPX socket
number. Although it never truly acts as a transport protocol
itself it is used to establish sessions between clients and
servers and barring well-known sockets is the only reliable way
to determine the protocol running over a given socket on a given
machine."
CHILDREN
"Children of SAP are identified by a 16 bit service type. They
are encoded as [ 0.0.a.b ], where 'a' is the MSB and 'b' is the
LSB of the service type.
Children of SAP are named as 'nov-sap a' where 'a' is the service
type in hexadecimal notation. The novell NCP protocol is
referred to as 'nov-sap ncp' OR 'nov-sap 0x0004'."
DECODING
"The first packet of any session for a SAP based application
(almost all IPX/PEP and IPX/SPX based applications utilize SAP)
is sent to the SAP server(s) to map the service type into a port
Bierman/Bucci/Iddon Expires January, 1998 [Page 122]
Draft RMON Protocol Identifiers July 1997
number for the host(s) on which the SAP server(s) is(are)
running. These initial packets are SAP packets and not
application packets and must be decoded accordingly.
Having established the mapping, clients will then send
application packets to the newly discovered socket number. These
must be decoded by 'remembering' the socket assignments
transmitted in the SAP packets.
In some cases the port mapping for a particular protocol is well
known and SAP will always return the same socket number for that
application.
Such programs should still be declared as children of nov-sap as
described under CHILDREN above. How an implementation detects a
client which is bypassing the SAP server to contact a well-known
application is beyond the scope of this document.
The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
the probe can (and should) monitor nov-sap activity to correctly
track SAP-based connections."
REFERENCE
"A list of SAP service types can be found at
ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-
numbers"
::= { nov-pep 0x0452,
ipx 0x0452 }
ncp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Netware Core Protocol"
CHILDREN
"Children of NCP are identified by the 8 bit command type field.
They are encoded as [ 0.0.0.a ] where 'a' is the command type
value.
Children of NCP are named as 'ncp a' where 'a' is the command
type in decimal notation. The NDS sub-protocol is referred to as
'ncp nds' OR 'ncp 104'."
Bierman/Bucci/Iddon Expires January, 1998 [Page 123]
Draft RMON Protocol Identifiers July 1997
DECODING
"Only the NCP request frames carry the command type field. How
the implementation infers the command type of a response frame is
an implementation specific matter and beyond the scope of this
document.
The tracksSessions(1) PARAMETERS bit indicates whether the probe
can (and should) perform command type inference."
REFERENCE
"[TBD]"
::= { nov-sap 0x0004,
ipx 0x0451 }
nds PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Netware Directory Services sub-protocol."
REFERENCE
"[TBD]"
::= { ncp 104 }
nov-diag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell's diagnostic Protocol"
REFERENCE
"[TBD]"
::= {
nov-sap 0x0017 -- this is the right one
-- [ed. this one is also typically true but, derivable from the one
-- above at run-time (I think this is the same thing).
-- ipx 0x0456]
}
nov-sec PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell security - serialization - copy protection protocol."
REFERENCE
"[TBD]"
::= { nov-pep 0x0457 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 124]
Draft RMON Protocol Identifiers July 1997
nov-watchdog PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell watchdog protocol."
REFERENCE
"[TBD]"
::= { nov-pep 0x4004 }
nov-bcast PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell broadcast protocol."
REFERENCE
"[TBD]"
::= { nov-pep 0x4005 }
5.4.3. The XEROX Protocol Stack
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order.
Children of IDP are encoded as [ 0.0.0.a ], and named as 'idp a'
where a is the packet type value. The XNS SPP protocol is
referred to as 'idp xns-spp' OR 'idp 2'."
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 ]
Bierman/Bucci/Iddon Expires January, 1998 [Page 125]
Draft RMON Protocol Identifiers July 1997
snap 0x600,
802-1Q 0x600 -- [ 0.0.6.0 ]
}
xns-rip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Routing Information Protocol."
REFERENCE
"[TBD]"
::= { idp 1 }
xns-echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS echo protocol."
REFERENCE
"[TBD]"
::= { idp 2 }
xns-error PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS error-handler protocol."
REFERENCE
"[TBD]"
::= { idp 3 }
xns-pep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"XNS Packet Exchange Protocol."
CHILDREN
"Children of PEP are defined by the 16 bit socket values. 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 socket value.
Each XNS/PEP packet contains two sockets, source and destination.
Bierman/Bucci/Iddon Expires January, 1998 [Page 126]
Draft RMON Protocol Identifiers July 1997
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"[TBD]"
::= { idp 4 }
xns-spp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Sequenced Packet Protocol."
CHILDREN
"Children of SPP are defined by the 16 bit socket values. 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 socket value.
Each XNS/SPP packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"[TBD]"
::= { idp 5 }
5.4.4. AppleTalk Protocol Stack
apple-oui PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol which binds Apple's protocols to vsnap."
CHILDREN
"Children of apple-oui are identified by the ether2 type field
value that the child uses when encapsulated in ether2. The value
is encoded into an octet string as [ 0.0.a.b ], where 'a' and 'b'
are the MSB and LSB of the 16-bit ether type value in network
byte order."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
vsnap 0x080007, -- [ 0.8.0.7 ]
Bierman/Bucci/Iddon Expires January, 1998 [Page 127]
Draft RMON Protocol Identifiers July 1997
802-1Q_vsnap 0x080007 -- [ 4.8.0.7 ]
}
aarp 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 ]
snap 0x80f3,
apple-oui 0x80f3,
802-1Q 0x80f3 -- [ 0.0.128.243 ]
}
-- Should we call this alap (as in ELAP and TLAP?)
-- Or perhaps DDP?
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."
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 ]
apple-oui 0x809b,
802-1Q 0x809b -- [ 0.0.128.155 ]
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 128]
Draft RMON Protocol Identifiers July 1997
rtmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Routing Table Maintenance Protocol."
REFERENCE
"[TBD]"
::= {
atalk 0x01, -- responses
atalk 0x05 -- requests
}
aep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Echo Protocol."
REFERENCE
"[TBD]"
::= { atalk 0x04 }
nbp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Name Binding Protocol."
DECODING
"In order to correctly identify the application protocol running
over atp NBP packets must be analyzed. The mechanism by which
this is achieved is beyond the scope of this document."
REFERENCE
"[TBD]"
::= { atalk 0x02 }
zip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Zone Information Protocol."
REFERENCE
"[TBD]"
::= {
atalk 0x06,
atp 3
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 129]
Draft RMON Protocol Identifiers July 1997
atp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"AppleTalk Transaction Protocol."
CHILDREN
"Children of atp are identified by the following (32 bit)
enumeration:
1 asp (AppleTalk Session Protocol)
2 pap (Printer Access Protocol)
3 zip (Zone Information Protocol)
Children of atp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
and 'd' are the four octets of the enumerated value in network
order (i.e. 'a' is the MSB and 'd' is the LSB).
The ZIP protocol is referred to as 'atp zip' OR 'atp 3'."
DECODING
"An implementation is encouraged to examine both the socket
fields in the associated DDP header as well as the contents of
prior NBP packets in order to determine which (if any) child is
present. A full description of this algorithm is beyond the
scope of this document. The tracksSessions(1) PARAMETER
indicates whether the probe can (and should) perform this
analysis."
REFERENCE
"[TBD]"
::= { atalk 0x03 }
adsp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"AppleTalk Data Stream Protocol."
CHILDREN
"Children of adsp are identified by enumeration. At this time
none are known."
DECODING
Bierman/Bucci/Iddon Expires January, 1998 [Page 130]
Draft RMON Protocol Identifiers July 1997
"An implementation is encouraged to examine the socket numbers in
the associated DDP header as well as the contents of prior NBP
packets in order to determine which (if any) child of ADSP is
present.
The mechanism by which this is achieved is beyond the scope of
this document.
The tracksSessions(1) PARAMETER indicates whether the probe can
(and should) perform this analysis."
REFERENCE
"[TBD]"
::= { atalk 0x07 }
asp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"AppleTalk Session Protocol."
CHILDREN
"Children of asp are identified by the following (32 bit)
enumeration:
1 afp (AppleTalk Filing Protocol)
Children of asp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
and 'd' are the four octets of the enumerated value in network
order (i.e. 'a' is the MSB and 'd' is the LSB).
The AFP protocol is referred to as 'asp afp' OR 'asp 1'."
DECODING
"ASP is a helper layer to assist in building client/server
protocols. It cooperates with ATP to achieve this; the
mechanisms used when decoding ATP apply equally here (i.e.
checking DDP socket numbers and tracking NBP packets).
Hence the tracksSessions(1) PARAMETER of atp applies to this
protocol also."
REFERENCE
"[TBD]"
::= { atp 1 }
afp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 131]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"AppleTalk Filing Protocol."
REFERENCE
"[TBD]"
::= { asp 1 }
pap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Printer Access Protocol."
REFERENCE
"[TBD]"
::= { atp 2 }
5.4.5. Banyon Vines Protocol Stack
-- vfrp PROTOCOL-IDENTIFIER
-- PARAMETERS {
-- countsFragments(0)
-- }
-- ATTRIBUTES {
-- hasChildren(0)
-- }
-- DESCRIPTION
-- "Vines Fragmentation Protocol header.
-- We will need this one for non-LAN media."
-- CHILDREN
-- "Children of vines-frp are identified by the etherType that they
-- would have used over ether2 encapsulation. It is an implementation
-- specific matter as to how these are determined in environments
-- where vines-frp is used."
-- ::= {
-- arcnet 0xf501 .. maps to vines-ip (0x0BAD)
-- arcnet 0xf502 .. maps to vines-echo (0x0BAF)
-- hdlc ????
-- ...
-- }
vtr PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
Bierman/Bucci/Iddon Expires January, 1998 [Page 132]
Draft RMON Protocol Identifiers July 1997
DESCRIPTION
"Banyan Vines Token Ring Protocol Header."
CHILDREN
"Children of vines-tr are identified by the 8 bit packet type
field. Children are encoded as [ 0.0.0.a ] where 'a' is the
packet type value.
The vines-ip protocol is referred to as 'vines-tr vip' OR
'vines-tr 0xba'."
REFERENCE
"See vip."
::= {
llc 0xBC, -- declared as any LLC, but really TR only.
802-1Q_llc 0xBC -- [2.0.0.188]
}
vecho PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines data link level echo protocol."
REFERENCE
"See vip."
::= {
ether2 0x0BAF, -- [0.0.11.175]
snap 0x0BAF,
-- vfrp 0x0BAF,
vtr 0xBB, -- [ed. yuck!]
802-1Q 0x0BAF -- [0.0.11.175]
}
vip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Banyan Vines Internet Protocol."
CHILDREN
"Children of vip are selected by the one-byte 'protocol type'
field located at offset 5 in the vip header. The value is
encoded as [ 0.0.0.a ], where a is the 'protocol type.' For
example, a protocolDirId fragment of:
Bierman/Bucci/Iddon Expires January, 1998 [Page 133]
Draft RMON Protocol Identifiers July 1997
0.0.0.1.0.0.11.173.0.0.0.1
identifies an encapsulation of vipc (ether2.vip.vipc)."
ADDRESS-FORMAT
"vip packets have 6-byte source and destination addresses. The
destination address is located at offset 6 in the vip header, and
the source address at offset 12. These are encoded in network
byte order."
REFERENCE
"Vines Protocol Definition - part# 092093-001, order# 003673
BANYAN,
120 Flanders Road,
Westboro, MA 01581 USA"
::= {
ether2 0x0BAD,
snap 0x0BAD,
-- vfrp 0x0BAD,
vtr 0xBA, -- [ed. yuck!]
802-1Q 0x0BAD -- [0.0.11.173]
}
varp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Address Resolution Protocol."
REFERENCE
"See vip."
::= { vip 0x04 }
vipc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Interprocess Communications Protocol."
CHILDREN
"Children of Vines IPC are identified by the packet type field at
offset 4 in the vipc header.
These are encoded as [ 0.0.0.a ] where 'a' is the packet type
value. Children of vipc are defined as 'vipc a' where 'a' is the
packet type value in hexadecimal notation.
Bierman/Bucci/Iddon Expires January, 1998 [Page 134]
Draft RMON Protocol Identifiers July 1997
The Vines Reliable Data Transport protocol is referred to as
'vipc vipc-rdp' OR 'vipc 0x01'."
DECODING
"Children of vipc are deemed to start at the first byte after the
packet type field (i.e. at offset 5 in the vipc header)."
REFERENCE
"See vip."
::= { vip 0x01 }
-- Banyan treats vipc, vipc-dgp and vipc-rdp as one protocol, IPC.
-- Vines IPC really comes in two flavours. The first is used to
-- send unreliable datagrams (vipc packet type 0x00). The second is used
-- to send reliable datagrams (vipc packet type 0x01),
-- consisting of up to four actual packets.
-- In order to distinguish between these we need two 'virtual' protocols
-- to identify which is which.
vipc-dgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Unreliable Datagram Protocol."
CHILDREN
"Children of vipc-dgp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vipc-dgp are defined as 'vipc-dgp a' where 'a' is the
port number in hexadecimal notation.
The StreetTalk protocol running over vipc-dgp would be referred
to as 'vipc-dgp streettalk' OR 'vipc-dgp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-dgp are deemed to start after the single
padding byte found in the vipc header. In the case of vipc-dgp
the vipc header is a so called 'short' header, total length 6
Bierman/Bucci/Iddon Expires January, 1998 [Page 135]
Draft RMON Protocol Identifiers July 1997
bytes (including the final padding byte)."
REFERENCE
"See vip."
::= { vipc 0x00 }
vipc-rdp PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Reliable Datagram Protocol."
CHILDREN
"Children of vipc-rdp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vipc-dgp are defined as 'vipc-rdp a' where 'a' is the
port number in hexadecimal notation.
The StreetTalk protocol running over vipc-rdp would be referred
to as 'vipc-rdp streettalk' OR 'vipc-rdp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-rdp are deemed to start after the error/length
field at the end of the vipc header. For vipc-rdp the vipc
header is a so called 'long' header, total 16 bytes (including
the final error/length field).
vipc-rdp includes a high level fragmentation scheme which allows
up to four vipc packets to be sent as a single atomic PDU. The
countsFragments(0) PARAMETERS bit indicates whether the probe can
(and should) identify the child protocol in all fragments or only
the leading one."
REFERENCE
"See vip."
::= { vipc 0x01 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 136]
Draft RMON Protocol Identifiers July 1997
vspp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Sequenced Packet Protocol."
CHILDREN
"Children of vspp are identified by the 16 bit port numbers
contained in the vspp header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vspp are defined as 'vspp a' where 'a' is the port
number in hexadecimal notation.
The StreetTalk protocol running over vspp would be referred to as
'vspp streettalk' OR 'vspp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"The implementation must ensure only those vspp packets which
contain application data are decoded and passed on to children.
Although it is suggested that the packet type and control fields
should be used to determine this fact it is beyond the scope of
this document to fully define the algorithm used."
REFERENCE
"See vip."
::= { vip 0x02 }
vrtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Routing Update Protocol."
REFERENCE
"See vip."
::= { vip 0x05 }
vicp PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 137]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Internet Control Protocol."
REFERENCE
"See vip."
::= { vip 0x06 }
-- [ed. - We have two choices how we do vines apps.
-- (1) The SUNRPC portmapper model.
-- This has to be the preferred way to define all NetRPC based programs,
-- i.e. by NetRPC program number.
-- (2) Really ignore NetRPC as there is no
-- good way to include it. Instead define NetRPC protocols as children
-- of vipc-rdp by port number. Works for well-known ones but dynamic
-- port numbers are used and NetRPC has a way of propagating these
-- (StreetTalk??).
-- So, if there is a portmapper-like program with a well known port number
-- we should define it as a child of vipc-rdp (and vipc-dgp I suspect) and
-- then declare all NetRPC based applications as children of this node by
-- program number. Use tracksSessions on the port mapper node to show
-- that you need to do this in order to follow the RPC sessions.]
5.4.6. The DECNet Protocol Stack
dec PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC [TBD]"
REFERENCE
"[TBD]"
::= {
ether2 0x6000,
802-1Q 0x6000 -- [0.0.96.0]
}
lat PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { } -- Should have children but I don't know how.
DESCRIPTION
"DEC Local Area Transport Protocol."
REFERENCE
Bierman/Bucci/Iddon Expires January, 1998 [Page 138]
Draft RMON Protocol Identifiers July 1997
"[TBD]"
::= {
ether2 0x6004,
802-1Q 0x6004 -- [0.0.96.4]
}
mop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Maintainance Operations Protocol."
REFERENCE
"[TBD]"
::= {
ether2 0x6001, -- mop dump/load
ether2 0x6002, -- mop remote console
802-1Q 0x6001, -- [0.0.96.1] VLAN + mop dump/load
802-1Q 0x6002 -- [0.0.96.2] VLAN + mop remote console
}
dec-diag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Diagnostic Protocol."
REFERENCE
"[TBD]"
::= {
ether2 0x6005,
802-1Q 0x6005 -- [0.0.96.5]
}
lavc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Local Area VAX Cluster Protocol."
REFERENCE
"[TBD]"
::= {
ether2 0x6007,
802-1Q 0x6007 -- [0.0.96.7]
}
drp PROTOCOL-IDENTIFIER
Bierman/Bucci/Iddon Expires January, 1998 [Page 139]
Draft RMON Protocol Identifiers July 1997
PARAMETERS {
countsFragments(1)
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DEC Routing Protocol."
CHILDREN
"There is only one child of DRP, NSP. This is encoded as [
0.0.0.1 ]."
ADDRESS-FORMAT
"There are three address formats used in DRP packets, 2-byte
(short data packet and all control except ethernet endnode &
router hello messages), 6-byte (ethernet router & endnode hello
messages) and 8-byte (long data packet). All of these contain
the 2-byte format address in the last 2 bytes with the remaining
bytes being unimportant for the purposes of system
identification. It is beyond the scope of this document to
define the algorithms used to identify packet types and hence
address formats.
The 2-byte address format is the concatenation of a 6-bit area
and a 10-bit node number. In all cases this is placed in little
endian format (i.e. LSB, MSB). The probe, however, will return
them in network order (MSB, LSB). Regardless of the address
format in the packet, the probe will always use the 2-byte
format.
For example area=13 (001101) and node=311 (0100110111) gives:
0011 0101 0011 0111 = 0x3537 in network order (the order the
probe should return the address in).
In packets this same value would appear as (hex):
2-byte 37 35
6-byte AA 00 04 00 37 35
8-byte 00 00 AA 00 04 00 37 35
Notice that the AA 00 04 00 prefix is defined in the
specification but is unimportant and should not be parsed.
Notice that control messages only have a source address in the
header and so they can never be added into the conversation based
Bierman/Bucci/Iddon Expires January, 1998 [Page 140]
Draft RMON Protocol Identifiers July 1997
tables."
DECODING
"NSP runs over DRP data packets; all other packet types are DRP
control packets of one sort or another and do not carry any
higher layer protocol.
NSP packets are deemed to start at the beginning of the DRP data
area.
Data packets may be fragmented over multiple DRP data packets.
The countsFragments(1) parameter indicates whether a probe can
(and should) attribute non-leading fragments to the child
protocol (above NSP in this case) or not.
Recognition of DRP data packets and fragments is beyond the scope
of this document."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
Routing Layer Functional Specification
Order# AA-X435A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= {
ether2 0x6003,
snap 0x6003,
802-1Q 0x6003 -- [0.0.96.3]
}
nsp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"DEC Network Services Protocol."
CHILDREN
"Children of NSP are identified by the SCP 8-bit object type.
Notice that the object type is included only in the session
establishment messages (connect initiate, retransmitted connect
initiate).
Children of NSP are encoded [ 0.0.0.a ] where 'a' is the SCP
object type. Children of NSP are named as 'nsp' followed by the
Bierman/Bucci/Iddon Expires January, 1998 [Page 141]
Draft RMON Protocol Identifiers July 1997
SCP object type in decimal. CTERM is referred to as 'nsp cterm'
OR 'nsp 42'."
DECODING
"An implementation is encouraged to examine SCP headers included
in NSP control messages in order to determine which child
protocol is present over a given session. It is beyond the scope
of this document to define the algorithm used to do this.
The tracksSessions(1) flag indicates whether the probe can (and
should) perform this analysis."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
NSP Functional Specification
Order# AA-X439A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= { drp 1 }
dap-v1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol version 1."
REFERENCE
"[TBD]"
::= { nsp 1 }
dap-v4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol versions 4 and above."
REFERENCE
"[TBD]"
::= { nsp 17 }
nice PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Network Information and Control Exchange protocol."
REFERENCE
"[TBD]"
::= { nsp 19 }
Bierman/Bucci/Iddon Expires January, 1998 [Page 142]
Draft RMON Protocol Identifiers July 1997
dec-loop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Loopback Protocol."
REFERENCE
"[TBD]"
::= { nsp 25 }
dec-event PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Event Protocol."
REFERENCE
"[TBD]"
::= { nsp 26 }
cterm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC CTERM Protocol."
REFERENCE
"[TBD]"
::= { nsp 42 }
5.4.7. The IBM SNA Protocol Stack.
sna-th PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
-- [ed. - clearly this really does have children, but I have
-- no idea what applications are at the top, so is it
-- worth expanding the hierarchy?]
DESCRIPTION
"IBM's SNA TH protocol."
REFERENCE
"IBM Systems Network Architecture
Format and Protocol
Reference Manual: Architectural Logic
SC30-3112-2
Bierman/Bucci/Iddon Expires January, 1998 [Page 143]
Draft RMON Protocol Identifiers July 1997
IBM System Communications Division,
Publications Development,
Department E02,
PO Box 12195,
Research Triangle Park,
North Carolina 27709."
::= {
llc 0x04, -- [0.0.0.4]
llc 0x08, -- [0.0.0.8]
llc 0x0c, -- [0.0.0.12]
ether2 0x80d5, -- [0.0.128.213]
802-1Q_llc 0x04, -- [2.0.0.4]
802-1Q_llc 0x08, -- [2.0.0.8]
802-1Q_llc 0x0c, -- [2.0.0.12]
802-1Q 0x80d5 -- [0.0.128.213]
}
5.4.8. The NetBEUI/NetBIOS Family
-- [ed. this comment needs fixing
-- CHILDREN OF NETBIOS
-- The NetBIOS/NetBEUI functions are implemented over a wide variety of
-- transports. Despite varying implementations they all share two
-- features. Firstly all sessions are established by connecting to
-- locally named services. Secondly all sessions transport application
-- between the client and the named service. In all cases the
-- identification of the application protocol carried within the data
-- packets is beyond the scope of this document.]
--
-- Children of NetBIOS/NetBEUI are identified by the following (32 bit)
-- enumeration
--
-- 1 smb (Microsoft's Server Message Block Protocol)
-- 2 notes (Lotus' Notes Protocol)
-- 3 cc-mail (Lotus' CC Mail Protocol)
--
-- Children of NetBIOS/NetBEUI are encoded as [ a.b.c.d ] where 'a', 'b',
-- 'c' and 'd' are the four octets of the enumerated value in network
-- order (i.e. 'a' is the MSB and 'd' is the LSB).
--
-- For example notes over NetBEUI is declared as
-- 'notes ::= { netbeui 2 }'
-- but is referred to as
-- 'netbeui notes' OR 'netbeui 2'.
Bierman/Bucci/Iddon Expires January, 1998 [Page 144]
Draft RMON Protocol Identifiers July 1997
netbeui PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Lan Manager NetBEUI protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
DECODING
"NETBEUI provides a named service lookup function. This function
allows clients to locate a service by (locally assigned) name. An
implementation is encouraged to follow lookups and session
establishments and having determined the child protocol, track
them.
How the child protocol is determined and how the sessions are
tracked is an implementation specific matter and is beyond the
scope of this document."
REFERENCE
"[TBD]"
::= {
llc 0xF0, -- [0.0.0.240]
802-1Q_llc 0xF0 -- [2.0.0.240]
}
nbt-name PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NetBIOS-over-TCP name protocol."
REFERENCE
"[TBD]"
::= {
udp 137,
tcp 137
}
nbt-session PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NetBIOS-over-TCP session protocol."
Bierman/Bucci/Iddon Expires January, 1998 [Page 145]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"[TBD]"
::= {
udp 139,
tcp 139
}
nbt-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"NetBIOS-over-TCP datagram protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"[TBD]"
::= {
udp 138,
tcp 138
}
netbios-3com PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"3COM NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"[TBD]"
::= {
ether2 0x3C00,
ether2 0x3C01,
ether2 0x3C02,
ether2 0x3C03,
ether2 0x3C04,
ether2 0x3C05,
ether2 0x3C06,
ether2 0x3C07,
ether2 0x3C08,
ether2 0x3C09,
Bierman/Bucci/Iddon Expires January, 1998 [Page 146]
Draft RMON Protocol Identifiers July 1997
ether2 0x3C0A,
ether2 0x3C0B,
ether2 0x3C0C,
ether2 0x3C0D,
802-1Q 0x3C00,
802-1Q 0x3C01,
802-1Q 0x3C02,
802-1Q 0x3C03,
802-1Q 0x3C04,
802-1Q 0x3C05,
802-1Q 0x3C06,
802-1Q 0x3C07,
802-1Q 0x3C08,
802-1Q 0x3C09,
802-1Q 0x3C0A,
802-1Q 0x3C0B,
802-1Q 0x3C0C,
802-1Q 0x3C0D
}
nov-netbios PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell's version of the NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"[TBD]"
::= {
nov-sap 0x0020, -- this is the right one to use
-- these are typically also true, but derivable from the one
-- above at run-time
-- ipx 0x14; when reached by IPX packet type
-- nov-pep 0x0455; when reached by socket number
ipx 0x0455
}
burst PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BURST [TBD]"
Bierman/Bucci/Iddon Expires January, 1998 [Page 147]
Draft RMON Protocol Identifiers July 1997
REFERENCE
"[TBD]"
::= { ipx 0x0d05 }
5.5. Multi-stack protocols
smb PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Microsoft Server Message Block Protocol."
REFERENCE
"[TBD]"
::= {
netbeui 1,
netbios-3com 1,
nov-netbios 1,
nbt-data 1,
nbt-session 1,
nov-pep 0x550,
nov-pep 0x552
-- vspp ???
-- xns-spp ???
}
notes PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lotus Notes Protocol."
REFERENCE
"[TBD]"
::= {
netbeui 2,
netbios-3com 2,
nov-netbios 2,
nbt-data 2,
tcp 1352,
udp 1352,
nov-sap 0x039b
}
ccmail PROTOCOL-IDENTIFIER
PARAMETERS { }
Bierman/Bucci/Iddon Expires January, 1998 [Page 148]
Draft RMON Protocol Identifiers July 1997
ATTRIBUTES { }
DESCRIPTION
"Lotus CC-mail Protocol."
REFERENCE
"[TBD]"
::= {
netbeui 3,
netbios-3com 3,
nov-netbios 3,
nbt-data 3,
tcp 3264,
udp 3264
}
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
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 161,
nov-pep 0x900f, -- [ 0.0.144.15 ]
atalk 8,
tcp 161
}
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,
nov-pep 0x9010,
Bierman/Bucci/Iddon Expires January, 1998 [Page 149]
Draft RMON Protocol Identifiers July 1997
atalk 9,
tcp 162
}
-- END
6. Acknowledgements
This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their contributions
to this document:
Anil Singhal
Frontier Software Development, Inc.
Jeanne Haney
Bay Networks
Dan Hansen
Network General Corp.
Special thanks are in order to the following people for writing RMON PI
macro compilers, and improving the specification of the PI macro
language:
David Perkins
Desktalk, Inc.
Skip Koppenhaver
Technically Elite, Inc.
Bierman/Bucci/Iddon Expires January, 1998 [Page 150]
Draft RMON Protocol Identifiers July 1997
7. References
[AF-LANE-0021.000]
LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over
ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995.
[AF-NM-TEST-0080.000]
Network Management Sub-working Group, Test Sub-working Group, A.
Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF-
NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997.
[IEEE802.1p]
802.1 Working Group, T. Jeffree, "Standard for Local and
Metropolitan Area Networks -- Supplement to Media Access Control
(MAC) Bridges: Traffic Class Expediting and Dynamic Multicast
Filtering", P802.1p/D6, LAN MAN Standards Committee of the IEEE
Computer Society, April 1997.
[IEEE802.1Q]
802.1 Working Group, T. Jeffree, "Draft Standard for Virtual
Bridged Local Area Networks", P802.1Q/D4, LAN MAN Standards
Committee of the IEEE Computer Society, December 1996.
[IEN158]
J. Haverty, "XNET Formats for Internet Protocol Version 4", IEN
158, October 1980.
[RFC407]
R. Bressler, R. Guida, A. McKenzie, "Remote Job Entry Protocol",
RFC 407, MIT-DMCG, BBN-NET, October 1972.
[RFC493]
J. Michener, I. Cotton, K. Kelley, D. Liddle, E. Meyer, "E.W., Jr
Graphics Protocol", RFC 493, April 1973.
[RFC734]
M. Crispin, "SUPDUP Protocol", RFC 734, SU-AI, October 1977.
[RFC740]
R. Braden, "NETRJS Protocol", RFC 740, UCLA-CCN, November 1977.
[RFC741]
D. Cohen, "Specifications for the Network Voice Protocol", RFC 741,
ISI/RR 7539, USC/Information Sciences Institute, March 1976.
Bierman/Bucci/Iddon Expires January, 1998 [Page 151]
Draft RMON Protocol Identifiers July 1997
[RFC759]
J. Postel, "Internet Message Protocol", RFC 759, USC/Information
Sciences Institute, August 1980.
[RFC768]
J. Postel, "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[RFC791]
J. Postel, "Internet Protocol - DARPA Internet Program Protocol
Specification", STD 5, RFC 791, USC/Information Sciences Institute,
September 1981.
[RFC792]
J. Postel, "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[RFC793]
J. Postel, "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 793, USC/Information Sciences
Institute, September 1981.
[RFC818]
J. Postel, "Remote User Telnet service", RFC 818, ISI, November
1982.
[RFC821]
J. Postel, "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1982.
[RFC823]
R. Hinden, A. Sheltzer, "The DARPA Internet Gateway", RFC 823, BBN,
September 1982.
[RFC826]
D. Plummer, "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]
J. Postel, J. Reynolds, "Telnet Protocol Specification", STD 8, RFC
854, ISI, May 1983.
Bierman/Bucci/Iddon Expires January, 1998 [Page 152]
Draft RMON Protocol Identifiers July 1997
[RFC862]
J. Postel, "Echo Protocol", STD 20, RFC 862, ISI, May 1983.
[RFC863]
J. Postel, "Discard Protocol", STD 21, RFC 863, ISI, May 1983.
[RFC864]
J. Postel, "Character Generator Protocol", STD 22, RFC 864, ISI,
May 1983.
[RFC865]
J. Postel, "Quote of the Day Protocol", RFC 865, ISI, May 1983.
[RFC866]
J. Postel, "Active Users", STD 26, RFC 866, ISI, May 1983.
[RFC867]
J. Postel, "Daytime Protocol", STD 25, RFC 867, ISI, May 1983.
[RFC868]
J. Postel, "Time Protocol", STD 26, RFC 868, ISI, May 1983.
[RFC869]
R. Hinden, "A Host Monitoring Protocol", RFC 869, Bolt Beranek and
Newman, December 1983.
[RFC887]
M. Accetta, "Resource Location Protocol", RFC 887, CMU, December
1983.
[RFC904]
International Telegraph and Telephone Co., D. Mills, "Exterior
Gateway Protocol Formal Specification", RFC 904, April 1984.
[RFC905]
International Standards Organization, A. McKenzie, "ISO Transport
Protocol Specification - ISO DP 8073", RFC 905, April 1984.
[RFC908]
D. Velten, R. Hinden, J. Sax, "Reliable Data Protocol", RFC 908,
BBN Communications Corporation, July 1984.
[RFC913]
M. Lottor, "Simple File Transfer Protocol", RFC 913, MIT, September
1984.
Bierman/Bucci/Iddon Expires January, 1998 [Page 153]
Draft RMON Protocol Identifiers July 1997
[RFC915]
M. Elvy, R. Nedved, "Network mail path service", RFC 915, Harvard
University, Carnegie-Mellon University, December 1984.
[RFC937]
M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, "Post
Office Protocol - version 2", RFC 937, ISI, February 1985.
[RFC938]
T. Miller, "Internet Reliable Transaction Protocol", RFC 938, ACC,
February 1985.
[RFC951]
W. Croft, J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsytems, September 1985.
[RFC953]
E. Feinler, K. Harrenstien, M. Stahl, "Hostname Server", RFC 953,
SRI, October 1985.
[RFC954]
E. Feinler, K. Harrenstien, M. Stahl, "NICNAME/WHOIS", RFC 954,
SRI, October 1985.
[RFC959]
J. Postel, J. Reynolds, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
[RFC972]
F. Wancho, "Password Generator Protocol", RFC 972, WSMR, January
1986.
[RFC977]
B. Kantor, P. Lapsley, "Network News Transfer Protocol: A Proposed
Standard for the Stream-Based Transmission of News", RFC 977, U.C.
San Diego, U.C. Berkeley, February 1986.
[RFC996]
D. Mills, "Statistics server", RFC 996, University of Delaware,
February 1987.
[RFC998]
D. Clark, M. Lambert, L. Zhang, "NETBLT: A Bulk Data Transfer
Protocol", RFC 998, MIT, March 1987.
Bierman/Bucci/Iddon Expires January, 1998 [Page 154]
Draft RMON Protocol Identifiers July 1997
[RFC1021]
C. Partridge, G. Trewitt, "High-level Entity Management System
HEMS", RFC 1021, BBN/NNSC, Stanford, October 1987.
[RFC1028]
J. Case, J. Davin, M. Fedor, M. Schoffstall, "Simple Gateway
Monitoring Protocol", RFC 1028, University of Tennessee at
Knoxville, Proteon, Inc., Cornell University, Rensselaer
Polytechnic Institute, November 1987.
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1056]
M. Lambert, "PCMAIL: A distributed mail system for personal
computers", RFC 1056, MIT, June 1988.
[RFC1057]
Sun Microsystems, Inc, "RPC: Remote Procedure Call Protocol
Specification version 2", RFC 1057, Sun Microsystems, Inc., June
1988.
[RFC1064]
M. Crispin, "Interactive Mail Access Protocol: Version 2", RFC
1064, SUMEX-AIM, July 1988.
[RFC1068]
A. DeSchon, R. Braden, "Background File Transfer Program BFTP",
RFC 1068, ISI, August 1988.
[RFC1070]
R. Hagens, N. Hall, M. Rose, "Use of the Internet as a subnetwork
for experimentation with the OSI network layer", RFC 1070, U of
Wiscsonsin - Madison, The Wollongong Group, February 1989.
[RFC1078]
M. Lottor, "TCP port service Multiplexer TCPMUX", RFC 1078, SRI-
NIC, November, 1988.
[RFC1086]
J. Onions, M. Rose, "ISO-TP0 bridge between TCP and X.25", RFC
1086, Nottingham, TWG, December 1988.
Bierman/Bucci/Iddon Expires January, 1998 [Page 155]
Draft RMON Protocol Identifiers July 1997
[RFC1095]
U. Warrier, L. Besaw, "Common Management Information Services and
Protocol over TCP/IP (CMOT)", RFC 1095, Unisys Corporation,
Hewlett-Packard, April 1989.
[RFC1112]
S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[RFC1157]
J. Case, M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[RFC1203]
J. Rice, "Interactive Mail Access Protocol - Version 3", RFC 1203,
Stanford, February 1991.
[RFC1204]
D. Lee, S. Yeh, "Message Posting Protocol (MPP)", RFC 1204, Netix
Communications, Inc., February 1991.
[RFC1213]
K. McCloghrie, M. Rose, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213,
Hughes LAN Systems, Performance Systems International, March 1991.
[RFC1226]
B. Kantor, "Internet Protocol Encapsulation of AX.25 Frames", RFC
1226, UCSD, May 1991.
[RFC1227]
M. Rose, "SNMP MUX Protocol and MIB", RFC 1227, Performance Systems
International, Inc., May 1991.
[RFC1234]
D. Provan, "Tunneling IPX Traffic through IP Networks", RFC 1234,
Novell, Inc., June 1991.
[RFC1235]
J. Ioannidis, G. Maguire, Jr., "The Coherent File Distribution
Protocol", RFC 1235, Columbia University, June 1991.
[RFC1241]
D. Mills, R. Woodburn, "A Scheme for an Internet Encapsulation
Bierman/Bucci/Iddon Expires January, 1998 [Page 156]
Draft RMON Protocol Identifiers July 1997
Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
1991.
[RFC1249]
T. Howes, M. Smith, B. Beecher, "DIXIE Protocol Specification", RFC
1249, University of Michigan, August 1991.
[RFC1267]
K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC
1267, Cisco Systems, T.J. Watson Research Center, IBM Corp.,
October 1991.
[RFC1282]
B. Kantor, "BSD Rlogin", RFC 1282, Univ. of Calif San Diego,
December 1991.
[RFC1288]
D. Zimmerman, "The Finger User Information Protocol", RFC 1288,
Center for Discrete Mathematics and Theoretical Computer Science,
December 1991.
[RFC1301]
S. Armstrong, A. Freier, K. Marzullo, "Multicast Transport
Protocol", RFC 1301, Xerox, Apple, Cornell, February 1992.
[RFC1305]
D. Mills, "Network Time Protocol (v3)", RFC 1305, University of
Delaware, April 1992.
[RFC1312]
R. Nelson, G. Arnold, "Message Send Protocol", RFC 1312, Crynwr
Software, Sun Microsystems, Inc., April 1992.
[RFC1339]
S. Dorner, P. Resnick, "Remote Mail Checking Protocol", RFC 1339,
U. of Illinois at Urbana-Champaign, June 1992.
[RFC1350]
K. Sollins, "TFTP Protocol (revision 2)", RFC 1350, MIT, July 1992.
[RFC1413]
M. St. Johns, "Identification Protocol", RFC 1413, US Department of
Defense, February 1993.
Bierman/Bucci/Iddon Expires January, 1998 [Page 157]
Draft RMON Protocol Identifiers July 1997
[RFC1419]
G. Minshall, M. Ritter, "SNMP over AppleTalk", RFC 1419, Novell,
Inc., Apple Computer, Inc., March 1993.
[RFC1420]
S. Bostock, "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
[RFC1436]
F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. John, D.
Torrey, B. Alberti, "The Internet Gopher Protocol (a distributed
document search and retrieval protocol)", RFC 1436, University of
Minnesota, March 1993.
[RFC1459]
J. Oikarinen, D. Reed, "Internet Relay Chat Protocol", RFC 1459,
May 1993.
[RFC1476]
R. Ullmann, "RAP: Internet Route Access Protocol", RFC 1476,
Process Software Corporation, June 1993.
[RFC1479]
M. Steenstrup, "Inter-Domain Policy Routing Protocol Specification:
Version 1", RFC 1479, BBN Systems and Technologies, July 1993.
[RFC1483]
J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer
5", RFC 1483, Telecom Finland, July 1993.
[RFC1492]
C. Finseth, "An Access Control Protocol, Sometimes Called TACACS",
RFC 1492, University of Minnesota, July 1993.
[RFC1510]
J. Kohl, B. Neuman, "The Kerberos Network Authentication Service
(V5)", RFC 1510, Digital Equipment Corporation, ISI, September
1993.
[RFC1573]
K. McCloghrie, F. Kastenholz, "Evolution of the Interfaces Group of
MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
[RFC1583]
J. Moy, "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
Bierman/Bucci/Iddon Expires January, 1998 [Page 158]
Draft RMON Protocol Identifiers July 1997
[RFC1700]
J Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[RFC1701]
S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, Netsmiths, Ltd., Cisco Systems,
October 1994.
[RFC1702]
S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing
Encapsulation over IPv4 networks", RFC 1702, Netsmiths, Ltd., Cisco
Systems, October 1994.
[RFC1725]
J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1725,
Carnegie Mellon, Dover Beach Consulting, November 1994.
[RFC1729]
C. Lynch, "Using the Z39.50 Information Retrieval Protocol in the
Internet Environment", RFC 1729, University of California, December
1994.
[RFC1730]
M. Crispin, "Internet Message Access ProtocolL - Version 4", RFC
1730, University of Washington, December 1994.
[RFC1739]
G. Kessler, S. Shepard, "A Primer On Internet and TCP/IP Tools",
RFC 1739, Hill Associates, Inc., December 1994.
[RFC1745]
K. Varadhan, S. Hares, Y. Rekhter, "BGP4/IDRP for IP---OSPF
Interaction", RFC 1745, OARnet & ISI, NSFnet/Merit, IBM, December
1994.
[RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
Mellon University, February 1995.
[RFC1777]
W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", Performance Systems International, University of
Michigan, ISODE Consortium, March 1995.
Bierman/Bucci/Iddon Expires January, 1998 [Page 159]
Draft RMON Protocol Identifiers July 1997
[RFC1782]
G. Malkin, A. Harkin, "TFTP Option Extension", RFC 1782, Xylogics,
Inc., Hewlett Packard Co., March 1995.
[RFC1783]
G. Malkin, A. Harkin, "TFTP BlockOption Option", RFC 1783,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1784]
G. Malkin, A. Harkin, "TFTP Timeout Interval and Transfer Size
Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
1995.
[RFC1798]
A. Young, "Connection-less Lightweight Directory Access Protocol",
RFC 1798, ISODE Consortium, June 1995.
[RFC1800]
J. Postel, "Internet Official Protocol Standards", STD 1, RFC 1800,
IAB, July 1995.
[RFC1813]
B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3 Protocol
Specification", RFC 1813, Sun Microsystems, Inc., June 1995.
[RFC1819]
L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2)", RFC 1819, ST2 Working Group, August 1995.
[RFC1831]
R. Srinivasan, "Remote Procedure Call Protocol Version 2", RFC
1831, Sun Microsystems, Inc., August 1995.
[RFC1853]
W. Simpson, "IP in IP Tunneling", RFC 1853, Daydreamer, October
1995.
[RFC1902]
J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1902, SNMP Research, Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
Bierman/Bucci/Iddon Expires January, 1998 [Page 160]
Draft RMON Protocol Identifiers July 1997
[RFC1903]
J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
Conventions for version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[RFC1904]
J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
Statements for version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[RFC1905]
J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Protocol
Operations for version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[RFC1906]
J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Transport Mappings
for Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach
Consulting, Inc., International Network Services, January 1996.
[RFC1940]
D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala, "Source
Demand Routing: Packet Format and Forwarding Specification (Version
1).", RFC 1940, USC, Cisco Systems, May 1996.
[RFC1945]
T. Berners-Lee, R. Fielding, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, MIT/LCS, UC-Irvine, November 1995.
[RFC2003]
C. Perkins, "IP Encapsulation within IP", RFC 2003, IBM, October
1996.
[RFC2021]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021,
International Network Services, January 1997.
Bierman/Bucci/Iddon Expires January, 1998 [Page 161]
Draft RMON Protocol Identifiers July 1997
[RFC2068]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DEC, MIT/LCS,
January 1997.
[RFC2069]
J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, E. L.
Stewart, "An Extension to HTTP: Digest Access Authentication", RFC
2069, CERN, Spyglass, Inc., Microsoft Corporation, Netscape
Communications Corporation, Open Market, Inc., January 1997.
[RFC2074]
A. Bierman, R. Iddon, "Remote Network Monitoring MIB Protocol
Identifiers", RFC 2074, Cisco Systems, AXON Networks Inc., January
1997.
[RFC2109]
D. Kristol, L. Montulli, "HTTP State Management Mechanism", RFC
2109, Bell Laboratories/Lucent Technologies, Netscape
Communications, February 1997.
[RFC2145]
J. Mogul, R. Fielding, J. Gettys, H. Frystyk, "Use and
interpretation of HTTP version numbers", RFC 2145, DEC, MIT/LCS,
May 1997.
Bierman/Bucci/Iddon Expires January, 1998 [Page 162]
Draft RMON Protocol Identifiers July 1997
8. Security Considerations
Security issues are not discussed in this memo.
9. Authors' Addresses
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: 408-527-3711
Email: abierman@cisco.com
Chris Bucci
Network General Corporation
[ed. - address and phone TBD]
Email: buccic@ngc.com
Robin Iddon
3Com Inc.
40/50 Blackfrias Street
Edinburgh, UK
Phone: +44 131.558.3888
Email: Robin_Iddon@3mail.3com.com
Bierman/Bucci/Iddon Expires January, 1998 [Page 163]
Draft RMON Protocol Identifiers July 1997
Table of Contents
1 Introduction .................................................... 2
2 The SNMP Network Management Framework ........................... 2
2.1 Object Definitions ............................................ 2
3 Overview ........................................................ 3
3.1 Terms ......................................................... 3
3.2 Relationship to the Remote Network Monitoring MIB ............. 5
3.3 Relationship to the ATM-RMON MIB .............................. 6
3.3.1 Port Aggregation ............................................ 6
3.3.2 Encapsulation Mappings ...................................... 6
3.3.3 Counting ATM Traffic in RMON2 Collections ................... 7
3.4 Relationship to the Other MIBs ................................ 7
4 Protocol Identifier Encoding .................................... 8
4.1 ProtocolDirTable INDEX Format Examples ........................ 11
4.2 Protocol Identifier Macro Format .............................. 12
4.2.1 Lexical Conventions ......................................... 12
4.2.2 Notation for Syntax Descriptions ............................ 13
4.2.3 Grammar for the PI Language ................................. 14
4.2.4 Mapping of the Protocol Name ................................ 15
4.2.5 Mapping of the VARIANT-OF Clause ............................ 16
4.2.6 Mapping of the PARAMETERS Clause ............................ 17
4.2.6.1 Mapping of the 'countsFragments(0)' BIT ................... 18
4.2.6.2 Mapping of the 'tracksSessions(1)' BIT .................... 19
4.2.7 Mapping of the ATTRIBUTES Clause ............................ 19
4.2.8 Mapping of the DESCRIPTION Clause ........................... 19
4.2.9 Mapping of the CHILDREN Clause .............................. 20
4.2.10 Mapping of the ADDRESS-FORMAT Clause ....................... 20
4.2.11 Mapping of the DECODING Clause ............................. 20
4.2.12 Mapping of the REFERENCE Clause ............................ 21
4.3 Evaluating a Protocol-Identifier INDEX ........................ 21
5 Protocol Identifier Macros ...................................... 23
5.1 Base Identifier Encoding ...................................... 23
5.1.1 Protocol Identifier Functions ............................... 23
5.1.1.1 Function 0: No-op ......................................... 24
5.1.1.2 Function 1: Protocol Wildcard Function .................... 24
5.2 Base Layer Protocol Identifiers ............................... 25
5.3 Encapsulation Layers .......................................... 32
5.3.1 IEEE 802.1Q ................................................. 32
5.4 Protocol Stacks And Single-Vendor Applications ................ 36
5.4.1 The TCP/IP protocol stack ................................... 36
5.4.2 Novell IPX Stack ............................................ 119
5.4.3 The XEROX Protocol Stack .................................... 125
5.4.4 AppleTalk Protocol Stack .................................... 127
Bierman/Bucci/Iddon Expires January, 1998 [Page 164]
Draft RMON Protocol Identifiers July 1997
5.4.5 Banyon Vines Protocol Stack ................................. 132
5.4.6 The DECNet Protocol Stack ................................... 138
5.4.7 The IBM SNA Protocol Stack. ................................ 143
5.4.8 The NetBEUI/NetBIOS Family .................................. 144
5.5 Multi-stack protocols ......................................... 148
6 Acknowledgements ................................................ 150
7 References ...................................................... 151
8 Security Considerations ......................................... 163
9 Authors' Addresses .............................................. 163
Bierman/Bucci/Iddon Expires January, 1998 [Page 165]
| PAFTECH AB 2003-2026 | 2026-04-24 04:47:04 |