Network Working Group A. Bierman
Request for Comments: 2074 Cisco Systems
Category: Standards Track R. Iddon
AXON Networks,Inc.
January 1997
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
1 Introduction
2 The SNMP Network Management Framework
2.1 Object Definitions
3 Overview
3.1 Terms
3.2 Relationship to the Remote Network Monitoring MIB
3.3 Relationship to the Other MIBs
4 Protocol Identifier Encoding
4.1 ProtocolDirTable INDEX Format Examples
4.2 Protocol Identifier Macro Format
4.2.1 Mapping of the Protocol Name
4.2.2 Mapping of the VARIANT-OF Clause
4.2.3 Mapping of the PARAMETERS Clause
4.2.3.1 Mapping of the 'countsFragments(0)' BIT
4.2.3.2 Mapping of the 'tracksSessions(1)' BIT
4.2.4 Mapping of the ATTRIBUTES Clause
4.2.5 Mapping of the DESCRIPTION Clause
4.2.6 Mapping of the CHILDREN Clause
4.2.7 Mapping of the ADDRESS-FORMAT Clause
4.2.8 Mapping of the DECODING Clause
4.2.9 Mapping of the REFERENCE Clause
4.2.10 Evaluating a Protocol-Identifier INDEX
5 Protocol Identifier Macros
5.1 Base Identifier Encoding
5.1.1 Protocol Identifier Functions
5.1.1.1 Function 0: No-op
5.1.1.2 Function 1: Protocol Wildcard Function
5.2 Base Layer Protocol Identifiers
5.2.1 Ether2 Encapsulation
5.2.2 LLC Encapsulation
5.2.3 SNAP over LLC (OUI=000) Encapsulation
5.2.4 SNAP over LLC (OUI != 000) Encapsulation
5.2.5 IANA Assigned Protocols
5.2.5.1 IANA Assigned Protocol Identifiers
5.3 L3: Children of Base Protocol Identifiers
5.3.1 IP
5.3.2 IPX
5.3.3 ARP
5.3.4 IDP
5.3.5 AppleTalk ARP
5.3.6 AppleTalk
5.4 L4: Children of L3 Protocols
5.4.1 ICMP
5.4.2 TCP
5.4.3 UDP
5.5 L5: Application Layer Protocols
5.5.1 FTP
5.5.1.1 FTP-DATA
5.5.1.2 FTP Control
5.5.2 Telnet
5.5.3 SMTP
5.5.4 DNS
5.5.5 BOOTP
5.5.5.1 Bootstrap Server Protocol
5.5.5.2 Bootstrap Client Protocol
5.5.6 TFTP
5.5.7 HTTP
5.5.8 POP3
5.5.9 SUNRPC
5.5.10 NFS
5.5.11 SNMP
5.5.11.1 SNMP Request/Response
5.5.11.2 SNMP Trap
6 Acknowledgements
7 References
8 Security Considerations
9 Authors' Addresses
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 [RMON2]. Although related to the original Remote Network Monitoring MIB [RFC1757], this document refers only to objects found in the RMON-2 MIB.
The SNMP Network Management Framework presently consists of three major components. They are:
- 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.
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.
The RMON-2 MIB [RMON2] 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.
Several terms are used throughout this document, as well as in the RMON-2 MIB [RMON2], that should be introduced:
- Name the protocol for use within the RMON-2 MIB [RMON2].
- Describe how the protocol is encoded into an octet string.
- Describe how child protocols are identified (if applicable),
and encoded into an octet string.
- Describe which protocolDirParameters are allowed for the protocol.
- Describe how the associated protocolDirType object is encoded
for the protocol.
- Provide reference(s) to authoritative documentation for the
protocol.
This document is intended to identify possible string values for the OCTET STRING objects protocolDirID and protocolDirParameters. Tables in the new Protocol Distribution, Host, and Matrix groups use a local INTEGER INDEX, in order to remain unaffected by changes in this document. Only the protocolDirTable uses the strings (protocolDirID and protocolDirParameters) described in this document.
This document is not intended to limit the protocols that may be
identified for counting in the RMON-2 MIB. Many protocol
encapsulations, not explicitly identified in this document, may be
present in an actual implementation of the protocolDirTable. Also,
implementations of the protocolDirTable may not include all the
protocols identified in the example section below.
This document 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://ftp.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 RMON standard. An agent should populate the directory with 'interesting' protocols--depending on the intended applications.
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.
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, (except for the 'vsnap' base layer) then it must be defined as a 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
The following figures show the differences between the 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 | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 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 'vsnap' base layer identifier is encoded into 8 sub-identifiers, All other protocol layers are either encoded into 4 sub-identifiers or encoded as a 'ianaAssigned' protocol.
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 or 8 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
|1/2| 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 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters
sub-identifiers.
Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 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.
-- 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(1)).snmp =
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0
-- SNMP over UDP/IP over any link layer
-- wildcard-ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2
-- wildcard-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).atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
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.
RMON-PROTOCOL-IDENTIFIER MACRO ::=
BEGIN
PIMacroName "PROTOCOL-IDENTIFIER"
VariantOfPart
"PARAMETERS" ParamPart
"ATTRIBUTES" AttrPart
"DESCRIPTION" Text
ChildDescrPart
AddrDescrPart
DecodeDescrPart
ReferPart
"::=" "{" EncapsPart "}"
PIMacroName ::=
identifier
VariantOfPart ::=
"VARIANT-OF" identifier | empty
ParamPart ::=
"{" ParamList "}"
ParamList ::=
Params | empty
Params ::=
Param | Params "," Param
Param ::=
identifier "(" nonNegativeNumber ")"
AttrPart ::=
"{" AttrList "}"
AttrList ::=
Attrs | empty
Attrs ::=
Attr | Attrs "," Attr
Attr ::=
identifier "(" nonNegativeNumber ")"
ChildDescrPart ::=
"CHILDREN" Text | empty
AddrDescrPart ::=
"ADDRESS-FORMAT" Text | empty
DecodeDescrPart ::=
"DECODING" Text | empty
ReferPart ::=
"REFERENCE" Text | empty
EncapsPart ::=
"{" Encaps "}"
Encaps ::=
Encap | Encaps "," Encap
Encap ::=
BaseEncap | NormalEncap | VsnapEncap | IanaEncap
BaseEncap ::=
nonNegativeNumber
NormalEncap ::=
identifier nonNegativeNumber
VsnapEncap ::=
identifier "(" nonNegativeNumber ")" nonNegativeNumber
IanaEncap ::=
"ianaAssigned" nonNegativeNumber
| "ianaAssigned" identifier
| "ianaAssigned" identifier "(" nonNegativeNumber ")"
Text ::=
"""" string """"
END
The 'PIMacroName' value should be a lower-case ASCII string, and contain the name or acronym identifying the protocol. NMS applications may treat protocol names as case-insensitive strings, and agent implementations must make sure the protocolDirTable does not contain any instances of the protocolDirDescr object which differ only in the case of one of more letters (if the identifiers are intended to represent different protocols).
It is possible that different encapsulations of the same protocol (which are represented by different entries in the protocolDirTable) will be assigned the same protocol name.
A protocol name should match the "most well-known" name or acronym for the indicated protocol. For example, the document indicated by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
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.
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 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 'ParamPart' and 'AttrPart' (i.e. "PARAMETERS {}") must be present in a protocol-variant-identifier macro, and the 'ParamPart' and 'AttrPart' found in the reference protocol- identifier macro examined instead.
Note that if a '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.
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.
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
------------------------------------
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.
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.
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.
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.
The DESCRIPTION clause provides a textual description of the protocol identified by this macro. Notice that it should not contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses.
The DESCRIPTION clause must be present in all protocol-identifier macro declarations.
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.
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.
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.
The DECODING clause is optional, and may be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol.
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).
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 anylink' 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, 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.).
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.
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.
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).
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)
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.
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 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. If an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation.
The agent may also be requested to count some or all of the
individual encapsulations for the same protocols, in addition to
wildcard counting. Note that the RMON-2 MIB [RMON2] does not require
that agents maintain 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.
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
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:
Children of 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 or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)."
REFERENCE
"A Standard for the Transmission of IP Datagrams over Ethernet
Networks; RFC 894 [RFC894].
The authoritative list of Ether Type values is identified by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
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 raw802.3 encapsulations). For 802.5 there is no other link layer protocol.
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
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
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 }
Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order. This is in turn followed by the 16-bit EtherType value, where the 'd' and 'e' represent the MSB and LSB of the EtherType, respectively.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7.0.0.128.155
defines the AppleTalk Phase 2 protocol over vsnap.
Note that two protocolDirParameters octets must be present in protocolDirTable INDEX values for 'vsnap' protocols. The first protocolDirParameters octet defines the actual parameters. The second protocolDirParameters octet is not used and must be set to zero.
Children are named as 'vsnap(<OUI>) <ethertype>', where the '<OUI>' field is represented as 3 octets in hexadecimal notation or the ASCII string associated with the OUI value. The
<ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named:
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero."
REFERENCE
"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 }
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 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 'ianaEnumerated' protocols.
IANA assigned protocols are identified by the base-layer-selector value [ 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.
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the name or numeric
of the particular IANA assigned protocol. The above
example would be named:
'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
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. 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.
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 }
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).
-- 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
"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,
ip 94
}
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
::= {
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)
}
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
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
}
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809b
}
::= { ip 1 }
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 }
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 }
::= { tcp 20 }
::= { tcp 21 }
::= { tcp 23 }
::= { tcp 25 }
::= { udp 53,
tcp 53 }
::= { udp 67 }
::= { udp 68 }
::= { udp 69 }
::= { tcp 80 }
::= { tcp 110 }
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
"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"
::= { udp 111 }
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 RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}
::= {
udp 162,
ipx 0x9010,
atalk 9
}
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.
Security issues are not discussed in this memo.
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