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 }
5.2.5.1. IANA Assigned Protocol Identifiers
The following protocol-variant-identifier macro declarations are used
to identify the RMONMIB IANA assigned protocols in a proprietary way,
by simple enumeration. Note that an additional four-octet layer
identifier may be used for some enumerations (as with the 'vsnap'
base-layer identifier). Refer to the 'CHILDREN' clause in the
protocol-identifier macro for a particular protocol to determine the
number of octets in the 'ianaAssigned' layer-identifier.
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 }
5.3. L3: Children of Base Protocol Identifiers
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.3.1. IP
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
[ 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
"RFC791 [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,
ip 94
}
5.3.2. IPX
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the
Destination Socket field. The value is encoded into an octet
string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
order encodings of the MSB and LSB of the destination socket
field."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"The IPX protocol is defined by the Novell Corporation
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}
5.3.3. ARP
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
5.3.4. IDP
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}
5.3.5. AppleTalk ARP
atalkarp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}
5.3.6. AppleTalk
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network byte
order."
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order".
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809b
}
5.4. L4: Children of L3 Protocols
5.4.1. ICMP
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol."
REFERENCE
"RFC792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 }
5.4.2. TCP
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol."
CHILDREN
"Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC793 [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 }
5.4.3. UDP
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol."
CHILDREN
"Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC768 [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 }
5.5. L5: Application Layer Protocols
5.5.1. FTP
5.5.1.1. FTP-DATA
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
5.5.1.2. FTP Control
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"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
"RFC959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }
5.5.2. Telnet
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
"RFC854 [RFC854] defines the basic Telnet Protocol."
::= { tcp 23 }
5.5.3. SMTP
smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
::= { tcp 25 }
5.5.4. DNS
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }
5.5.5. BOOTP
5.5.5.1. Bootstrap Server Protocol
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }
5.5.5.2. Bootstrap Client Protocol
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }
5.5.6. TFTP
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
"RFC1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
1782 [RFC1782] defines TFTP Option Extensions; RFC1783 [RFC1783]
defines the TFTP Blocksize Option; RFC1784 [RFC1784] defines
TFTP Timeout Interval and Transfer Size Options."
::= { udp 69 }
5.5.7. HTTP
www-http PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol; "
REFERENCE
"RFC1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0)."
::= { tcp 80 }
5.5.8. POP3
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
::= { tcp 110 }
5.5.9. SUNRPC
sunrpc PROTOCOL-IDENTIFIER
PARAMETERS { }
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 of the
function identifier value.
From [RFC1831]:
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'.
REFERENCE
"RFC1831 [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"
::= { udp 111 }
5.5.10. NFS
nfs PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"The first packet in an NFS transaction is sent to the port-
mapper, and therefore decoded statically by monitoring RFC
portmap requests [RFC1831]. Any subsequent NFS fragments must be
decoded and correctly identified by 'remembering' the port
assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
The 'countsFragments(0)' PARAMETER bit is used to indicate
whether the probe can (and should) monitor portmapper activity to
correctly attribute all NFS packets."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
5.5.11. SNMP
5.5.11.1. SNMP Request/Response
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 RFC1902 [RFC1902]. The SNMP
protocol is defined in RFC1905 [RFC1905]. Transport mappings
are defined in RFC1906 [RFC1906]; RFC1420 (SNMP over IPX)
[RFC1420]; RFC1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}
5.5.11.2. SNMP Trap
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC1902 [RFC1902]. The SNMP
protocol is defined in RFC1905 [RFC1905]. Transport mappings
are defined in RFC1906 [RFC1906]; RFC1420 (SNMP over IPX)
[RFC1420]; RFC1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
ipx 0x9010,
atalk 9
}
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.
7. References
[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC768,
USC/Information Sciences Institute, August 1980.
[RFC791]
Postel, J., ed., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC791, USC/Information Sciences
Institute, September 1981.
[RFC792]
Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC792, USC/Information
Sciences Institute, September 1981.
[RFC793]
Postel, J., "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC793, USC/Information Sciences
Institute, September 1981.
[RFC821]
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
USC/Information Sciences Institute, August 1982.
[RFC826]
Plummer, D., "An Ethernet Address Resolution Protocol or
"Converting Network Protocol Addresses to 48-bit Ethernet Addresses
for Transmission on Ethernet Hardware", STD 37, RFC826, MIT-LCS,
November 1982.
[RFC854]
Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC854, ISI, May 1983.
[RFC894]
Hornig, C., "A Standard for the Transmission of IP Datagrams over
Ethernet Networks", RFC894, Symbolics, April 1984.
[RFC951]
Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC951,
Stanford and SUN Microsytems, September 1985.
[RFC959]
Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8,
RFC959, USC/Information Sciences Institute, October 1985.
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and Specification",
STD 13, RFC1035, USC/Information Sciences Institute, November
1987.
[RFC1157]
Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", STD 15, RFC1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1350]
Sollins, K., "TFTP Protocol (revision 2)", RFC1350, MIT, July
1992.
[RFC1419]
Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC1419,
Novell, Inc., Apple Computer, Inc., March 1993.
[RFC1420]
Bostock, S., "SNMP over IPX", RFC1420, Novell, Inc., March 1993.
[RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
USC/Information Sciences Institute, October 1994.
[RFC1725]
Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
[RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC1757, Carnegie
Mellon University, February 1995.
[RFC1782]
Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC1782,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1783]
Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC1783,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1784]
Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
Options", RFC1784, Xylogics, Inc., Hewlett Packard Co., March
1995.
[RFC1800]
Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
RFC1920, IAB, March 1996.
[RFC1831]
Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
1831, Sun Microsystems, Inc., August 1995.
[RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC1902,
January 1996.
[RFC1903]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1903, January 1996.
[RFC1904]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1904, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, January 1996.
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1906, January 1996.
[RFC1945]
Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
HTTP/1.0", RFC1945, MIT/UC-Irvine, November 1995.
[RMON2]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
ietf-rmonmib-rmon2-03.txt, International Network Services, January
1996.
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
Robin Iddon
3Com/AXON
40/50 Blackfrias Street
Edinburgh, UK
Phone: +44 131.558.3888
EMail: robin_iddon@3mail.3com.com