HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:07:37 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 17 Nov 1995 23:00:00 GMT ETag: "304f55-ecb4-30ad13f0" Accept-Ranges: bytes Content-Length: 60596 Connection: close Content-Type: text/plain Draft RMON Protocol Identifiers November 17, 1995 Remote Network Monitoring MIB Protocol Identifiers 17 November 1995 Andy Bierman Bierman Consulting abierman@west.net Robin Iddon AXON Networks, Inc. robini@axon.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Bierman/Iddon Expires May 17, 1996 [Page 1] Draft RMON Protocol Identifiers November 17, 1995 1. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 (RMON-2) [RMON2]. Although related to the original Remote Network Monitoring MIB (RMON) [RFC1757], this document refers only to objects found in the RMON-2 MIB. 1.1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [RFC1442] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [RFC1213] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [RFC1445] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [RFC1448] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Bierman/Iddon Expires May 17, 1996 [Page 2] Draft RMON Protocol Identifiers November 17, 1995 2. Overview The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to globally identify specific protocol encapsulations in the protocolDirTable. This guide contains algorithms and examples of protocol identifier encapsulations for use as INDEX values in the protocolDirTable. This document is not intended to be an authoritative reference on the protocols described herein. Refer to the Official Internet Standards document (RFC 1800) [RFC1800], the Assigned Numbers document (RFC 1700) [RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete and authoritative protocol information. 2.1. Terms Several terms are used throughout this document, as well as in the RMON-2 MIB [RMON2], that should be introduced: layer-identifier: An octet string fragment representing a particular protocol encapsulation layer. A layer-identifier is composed of one or more layer-identifier-components. An implementation must recognize the number of layer-identifier-components in a non-standard way, since there is no layer-identifier-component-count octet encoded into a protocol-identifier string. layer-identifier-component: A four-octet string fragment identifying some or all of a particular protocol encapsulation layer. This string is always exactly four octets in length and encoded in network byte order. A particular protocol encapsulation can be identified by starting with a MAC layer encapsulation (see the 'L2 Protocol Identifiers' section for more detail), and following the encoding rules specified in the CHILDREN clause and assignment section for that layer. Then repeat for each identified layer in the encapsulation. (See the section 'Evaluating a Protocol-Identifier INDEX' for more detail.) protocol: A particular protocol layer, as specified by encoding rules in this document. Usually refers to a single layer in a given encapsulation. Note that this term is sometimes used in the RMON-2 Bierman/Iddon Expires May 17, 1996 [Page 3] Draft RMON Protocol Identifiers November 17, 1995 MIB [RMON2] to name a fully-specified protocol-identifier string. In such a case, the protocol-identifier string is named for its upper-most layer. A named protocol may also refer to any encapsulation of that protocol. protocol-identifier string: An octet string representing a particular protocol encapsulation, as specified by encoding rules in this document. This string is identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A protocol protocol-identifier string is composed of one or more layer-identifiers. protocol-identifier macro: A group of formatted text describing a particular protocol layer, as used within the RMON-2 MIB [RMON2]. The macro serves several purposes: - Name the protocol for use within the RMON-2 MIB [RMON2]. - Describe how the protocol is encoded into an octet string. - Describe how child protocols are identified (if applicable), and encoded into an octet string. - Describe which protocolDirParameters are allowed for the protocol. - Describe how the associated protocolDirType object is encoded for the protocol. - Provide reference(s) to authoritative documentation for the protocol. protocol-parameter: A single octet, corresponding to a specific layer-identifier- component in the protocol-identifier. This octet is a bit-mask indicating special functions or capabilities that this agent is providing for the corresponding protocol. protocol-parameters string: An octet string, which contains one protocol-parameter for each layer-identifier-component in the protocol-identifier. See the section 'Mapping of the PARAMETERS Clause' for more detail. This string is identified in the RMON-2 MIB [RMON2] as the protocolDirParameters object. protocolDirTable INDEX: A protocol-identifier and protocol-parameters octet string pair that have been converted to an INDEX value, according to the encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212]. Bierman/Iddon Expires May 17, 1996 [Page 4] Draft RMON Protocol Identifiers November 17, 1995 pseudo-protocol: A convention or algorithm used only within this document for the purpose of encoding protocol-identifier strings. 2.2. Relationship to the Remote Network Monitoring MIB This document is intended to identify possible string values for the OCTET STRING objects protocolDirID and protocolDirParameters. Tables in the new Protocol Distribution, Host, and Matrix groups use a local INTEGER INDEX, in order to remain unaffected by changes in this document. Only the protocolDirTable uses the strings (protocolDirID and protocolDirParameters) described in this document. This document is not intended to limit the protocols that may be identified for counting in the RMON-2 MIB. Many protocol encapsulations, not explicitly identified in this document, may be present in an actual implementation of the protocolDirTable. Also, implementations of the protocolDirTable may not include all the protocols identified in the example section below. 2.3. Relationship to the Other MIBs The RMON Protocol Identifiers document is intended for use with the protocolDirTable within the RMON MIB. It is not relevant to any other MIB, or intended for use with any other MIB. Bierman/Iddon Expires May 17, 1996 [Page 5] Draft RMON Protocol Identifiers November 17, 1995 3. Protocol Identifier Encoding The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable-length string is converted to an OBJECT IDENTIFIER fragment, according to the encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212]. Then the index fragments are simply concatenated. (Refer to figures 1a - 1d below for more detail.) The first OCTET STRING (protocolDirID) is composed of one or more 4- octet "layer-identifiers". The entire string uniquely identifies a particular protocol encapsulation tree. The second OCTET STRING, (protocolDirParameters) which contains a corresponding number of 1-octet protocol-specific parameters, one for each 4-octet layer-identifier in the first string. A protocol layer is identified by one or more 32-bit values. Each layer-identifier-value is encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of the 32-bit value in network byte order. Notice that each encapsulating layer may use one or more of these layer identifiers to indicate the encapsulated protocol. However, there are no actual cases included in this document where this was required. An implementation must determine how many layer-identifiers Bierman/Iddon Expires May 17, 1996 [Page 6] Draft RMON Protocol Identifiers November 17, 1995 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 Detail ------------------------------------ protocolDirID protocolDirParameters +---+--------+--------+--------+--------+---+---+---+---+---+ | c | proto | proto | proto | proto | c |par|par|par|par| | n | L2 | L3 | L4 | L5 | n | L2| L3| L4| L5| | t | | | | | t | | | | | +---+--------+--------+--------+--------+---+---+---+---+---+ subOID | 1 | 4 * N2 | 4 * N3 | 4 * N4 | 4 * N5 | 1 | N2| N3| N4| N5| count where Ni is the number of protocol-layer-values required for protocol layer 'i', and 'subOID' is a single Bierman/Iddon Expires May 17, 1996 [Page 7] Draft RMON Protocol Identifiers November 17, 1995 OBJECT IDENTIFIER sub-identifier. Fig. 1d protocolDirTable OCTET STRING Format Detail ------------------------------------------- protocolDirID +--------+--------+--------+--------+ | proto | proto | proto | proto | | L2 | L3 | L4 | L5 | | | | | | +--------+--------+--------+--------+ octet | 4 * N2 | 4 * N3 | 4 * N4 | 4 * N5 | count protocolDirParameters +---+---+---+---+ |par|par|par|par| | L2| L3| L4| L5| | | | | | +---+---+---+---+ octet | N2| N3| N4| N5| count where Ni is the number of protocol-layer-values required for protocol layer 'i'. 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.) Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 7.1.3 of RFC 1442 [RFC1442]. 3.1. ProtocolDirTable INDEX Format Examples -- HTTP; fragments counted from IP and above ether2.ip.tcp.www-http = 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0 -- SNMP over UDP/IP over SNAP snap.ip.udp.snmp = 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 Bierman/Iddon Expires May 17, 1996 [Page 8] Draft RMON Protocol Identifiers November 17, 1995 -- SNMP over IPX over SNAP snap.ipx.snmp = 12.0.0.0.3.0.0.129.55.0.0.0.161.3.0.0.0 -- SNMP over IPX over raw8023 raw8023.ipx.snmp = 12.0.0.0.5.0.0.129.55.0.0.0.161.3.0.0.0 -- IPX over LLC llc.ipx = 8.0.0.0.2.0.224.224.3.2.0.0 -- SNMP over UDP/IP over any link layer -- wildcard-ether2.ip.udp.snmp 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 -- LLC 'others' pseudo-protocol 4.0.0.0.2.1.2 -- IP over any link layer 'others' pseudo-protocol -- wildcard-ether2.ip(others) 8.1.0.0.1.0.0.8.0.2.0.2 3.2. Protocol Identifier Macro Format The following example is meant to introduce the PROTOCOL-IDENTIFIER macro syntax. The syntax is not ASN.1; The definitive BNF definitions for the protocol-identifier macro syntax can be found in Appendix A. protocol-identifier :== "PROTOCOL-IDENTIFIER" "PARAMETERS" "{" "}" "ATTRIBUTES" "{" "}" "DESCRIPTION" """ """ [ "CHILDREN" """ """ ] [ "ADDRESS-FORMAT" """ """ ] [ "DECODING" """ """ ] [ "REFERENCE" """ """ ] "::=" "{" "}" 3.2.1. Mapping of the Protocol Name The 'protocol-name' value must be an lower-case ASCII string, and if possible, should match the "most well-known" name or acronym for the Bierman/Iddon Expires May 17, 1996 [Page 9] Draft RMON Protocol Identifiers November 17, 1995 indicated protocol. For example, the document indicated by the URL: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers defines IP Protocol field values, so protocol-identifier macros for children of IP should be given names consistent with the protocol names found in this authoritative document. 3.2.2. Mapping of the PARAMETERS Clause The PARAMETERS clause is a list of bit definitions which can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions may be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conformant agent may choose to implement a subset of zero or more of these PARAMETERS. By convention, the following common bit definitions are used by different protocols. These bit positions must not be used for other parameters. They should be reserved if not used by a given protocol. Bierman/Iddon Expires May 17, 1996 [Page 10] Draft RMON Protocol Identifiers November 17, 1995 Table 3.1 Reserved PARAMETERS Bits ------------------------------------ Bit Name Description --------------------------------------------------------------------- 0 countsFragments higher-layer protocols encapsulated within this protocol will be counted correctly even if this protocol fragments the upper layers into multiple packets. 1 others this parameter is used to identify a 'pseudo- protocol' -- the children of the protocol encapsulation identified by the protocolDirID portion of the INDEX, which are not otherwise identified by entries in the protocolDirTable. This is a valid parameter for all extensible protocols. 2 trackSessions correctly attributes all packets of a protocol which starts sessions on well known ports or sockets and then transfers them to dynamically assigned ports or sockets thereafter (e.g. TFTP). The PARAMETERS clause must be present in all protocol-identifier macro declarations, but may be empty. 3.2.2.1. Mapping of the 'countsFragments(0)' BIT This bit indicates whether the probe is correctly attributing all fragmented packets of the specified protocol, even if individual frames carrying this protocol cannot be identified as such. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS. This bit may only be set in a protocolDirParameters octet which corresponds to a protocol that supports fragmentation and reassembly in some form. Note that TCP packets are not considered 'fragmented-streams' and so TCP is not eligible. This bit may be set in at most one protocolDirParameter octet within a protocolDirTable INDEX. Bierman/Iddon Expires May 17, 1996 [Page 11] Draft RMON Protocol Identifiers November 17, 1995 3.2.2.2. Mapping of the 'others(1)' BIT The 'others(1)' BIT is handled in a special way. The unique OCTET STRING created with the others(1) bit set in the last protocolDirParameters octet identifies the 'others' pseudo-protocol. Note that corresponding protocolDirEntry, (i.e. identical, but without the 'others' bit set), may or may not be present in the protocolDirTable. Only the un-attributed protocols ('others') counters are kept for this pseudo-protocol. If the unknown protocol occurs above the network layer, then host and matrix entries can be maintained for the 'others' entry, otherwise only a protocol distribution entry can be kept. Only the last protocol specified in the protocolDirID can set the 'others' bit in the corresponding protocolDirParameters octet. For example, to indicate all unknown ETHER TYPES, the protocol identifier '4.0.0.0.1.1.2' would be used. An agent might assign this protocol a local index value of '42'. After creating the appropriate control entry, protocolDistStatsPkts.1.42 would contain the unknown ETHER TYPES packet count, and protocolDistStatsOctets.1.42 would contain the unknown ETHER TYPES octet count. The following examples show identifiers for 'ip(others)' and 'tcp(others)' ether2.ip(others) = 8.0.0.0.1.0.0.8.0.0.2.0.2 ether2.ip.tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.0.2 -- the following identifier is illegal ether2.ip(others).tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.2.2 3.2.2.2.1. Relationship to the protocolDirTable The protocol-collection control objects (e.g. protocolDirHostConfig) can affect the overall consistency of counter values retrieved by a management station, since collection of given protocols can be enabled or disabled while collection is running. Also, protocols may be added to the protocolDirTable while collections are in progress. The following 'counting' rules must be implemented by a probe to ensure that consistent data is returned to the management station: Bierman/Iddon Expires May 17, 1996 [Page 12] Draft RMON Protocol Identifiers November 17, 1995 - If collection of a child protocol is disabled in a given table with one of the protocolDir*Config objects, then the counts for this protocol are 'conceptually' added to the 'parent-protocol' counter, if that protocol is being counted. This action must be transparent to the management station, since counters for the parent-protocol cannot be affected by configuration switches for upper-layer protocols. - If collection of a child protocol is enabled at some time after collection of 'others' counts for the parent has begun, (either because some instance of protocolDir*Config was changed or a new protocolDirEntry was created), then the probe must ensure that all counter values are consistent after the child protocol collection begins. An RMON-2 probe is required to instantiate counters with a value of zero, which should be enough to meet this requirement. 3.2.2.3. Mapping of the 'tracksSessions(2)' BIT The 'tracksSessions(2)' 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 'trackSessions' parameter are independent of the other protocolDirParameter definitions, so this parameter may be combined with any other legal parameter configurations. 3.2.3. Mapping of the ATTRIBUTES Clause The ATTRIBUTES clause is a list of bit definitions which are directly encoded into the associated instance of ProtocolDirType. The BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object. Bierman/Iddon Expires May 17, 1996 [Page 13] Draft RMON Protocol Identifiers November 17, 1995 Table 3.2 Reserved ATTRIBUTES Bits ------------------------------------ Bit Name Description --------------------------------------------------------------------- 0 hasChildren indicates that there may be children of this protocol defined in the protocolDirTable (by either the agent or the manager). 1 addressRecognitionCapable indicates that this protocol can be used to generate host and matrix table entries. The ATTRIBUTES clause must be present in all protocol-identifier macro declarations, but may be empty. 3.2.4. Mapping of the DESCRIPTION Clause The DESCRIPTION clause provides a textual description of the protocol identified by this macro. Notice that it should not contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses. The DESCRIPTION clause must be present in all protocol-identifier macro declarations. 3.2.5. Mapping of the CHILDREN Clause The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections: - Details on the field(s)/value(s) used to select the child protocol, and how that selection process is performed - Details on how the value(s) are encoded in the protocol identifier octet string - Details on how child protocols are named with respect to their parent protocol label(s) The CHILDREN clause must be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause. Bierman/Iddon Expires May 17, 1996 [Page 14] Draft RMON Protocol Identifiers November 17, 1995 3.2.6. Mapping of the ADDRESS-FORMAT Clause The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses. This clause must be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause. 3.2.7. 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 BIT set) this includes offset and type information for the field(s) used for child selection as well as information on determining the start of the child protocol. For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses. The DECODING clause is optional, and may be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol. 3.2.8. 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 & address of the controlling body. The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the amount of information which may already be obtained from an 'authoritative' document, such as the Assigned Numbers document (RFC 1700) [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document. The REFERENCE clause is optional, but should be implemented if an authoritative reference exists for the protocol (especially for standard protocols). Bierman/Iddon Expires May 17, 1996 [Page 15] Draft RMON Protocol Identifiers November 17, 1995 3.2.9. Evaluating a Protocol-Identifier INDEX The following evaluation is done after protocolDirTable INDEX value has been converted into two OCTET STRINGs according to the INDEX encoding rules specified in RFC 1212. Protocol-identifiers are evaluated left-to-right, starting with the protocolDirID, which length should be evenly divisible by four. The protocolDirParameters length should be exactly one quarter of the protocolDirID string length. Protocol-identifier parsing starts with the MAC layer identifier, which must be present, and continues for one or more upper layer identifiers, until all OCTETs of the protocolDirID have been used. Layers may not be skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can not exist. Wild-carding is only supported at the MAC layer (see the 'L2 Protocol Identifiers' section for MAC-wildcard details). After the protocol-tree identified in protocolDirID has been parsed, each parameter bit-mask (one octet for each 4-octet layer-identifier- component) is evaluated, and applied to the corresponding protocol layer. Note that the 'others(1)' BIT may only be set once in a protocolDirParameters string, and that this has to occur in the last octet of the string. This bit is only applicable for protocols in which the 'hasChildren' ATTRIBUTE bit is set. An agent should reject SetRequests in which the 'others(1)' bit in protocolDirParameters is set in any other manner. A protocol-identifier label may map to more than one value. For instance, 'ip' maps to 5 distinct values, one for each supported encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'), It is important to note that these macros are conceptually expanded at implementation time, not at run time. If all the macros are expanded completely by substituting all possible values of each label for each child protocol 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. Bierman/Iddon Expires May 17, 1996 [Page 16] Draft RMON Protocol Identifiers November 17, 1995 4. Protocol Identifier Macro Examples The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParmaters strings. This section is intended to grow over time. Minimal protocol support is included at this time. 4.1. L2 Protocol Identifiers The first layer (L2) is mandatory, and defines the MAC encapsulation of the packet. The MAC layer encapsulation is encoded in an octet string as a 4-octet layer identifier, of the form: w.0.a.b where 'w' is the 'anylink' wildcard indicator, and 'a' and 'b' are the network byte order encodings of the MSB and LSB of the "ID" field in table below. The wildcard indicator (0==no wildcard, 1==wildcard), is used to flag the special pseudo-MAC-layer for the purpose of aggregating counts. If the wildcard flag is set in an protocol identifier, then the encapsulation given in 'a.b', (called the 'base encapsulation') is used simply to identify the rest of the protocol layers. This base encapsulation should be the 'ether2' encapsulation, if possible. Note that only one net-layer-encapsulation is actually encoded into the protocol identifier. An agent will need to identify other encapsulations of the indicated network-layer protocol in an implementation-specific manner, and count all matching encapsulations which are part of this 'wildcard' protocol. The agent may also be requested to count some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. There is one value for protocolDirParameters defined for the MAC layer at this time; the 'others' counter can be supported at this layer. The suggested ProtocolDirDescr field for the MAC layer is given by the corresponding "Name" field in the table 4.1 below. However, implementations may choose different values. Bierman/Iddon Expires May 17, 1996 [Page 17] Draft RMON Protocol Identifiers November 17, 1995 The MAC layer protocolDirType field should contain bits set for the "hasChildren(0)" and "addressRecognitionCapable(1)" attributes. Table 4.1 MAC Layer Encoding Values ------------------------------------- Name ID ------------------ ether2 1 llc 2 snap 3 vsnap 4 raw8023 5 4.1.1. Ether2 Encapsulation ether2 PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of ether2 packets that didn't match -- any children of ether2 enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "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 value of: 8.0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. Children of are named as 'ether2' followed by the type field Bierman/Iddon Expires May 17, 1996 [Page 18] Draft RMON Protocol Identifiers November 17, 1995 value in hexadecimal. The above example would be declared as: ether2 0x0800" ADDRESS-FORMAT "Ethernet addresses are 6 octets in network order." DECODING "Only type values greater than or equal to 1500 decimal indicate Ethernet-II frames; lower values indicate 802.3 encapsulation (see below)." REFERENCE "RFC 894; The authoritative list of Ether Type values is identified by the URL: ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" ::= { 1 } 4.1.2. LLC Encapsulation llc PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of llc packets that didn't match -- any children of llc enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "The LLC (802.2) protocol." CHILDREN "The LLC SSAP and DSAP (Source/Dest Service Access Points) are used to select child protocols. Each of these is one octet long, although the least significant bit is a control bit and should be masked out. Typically SSAP and DSAP (once masked) are the same for a given protocol - each end implicitly knows whether it is the server or client in a client/server protocol. This is only a convention, however, and it is possible for them to be different. The SSAP is matched against child protocols first. If none is found then the DSAP is matched instead. The child protocol is deemed to start at the first octet after the LLC control field(s). Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol identifier for LLC followed by [ 0.0.0.a ] where 'a' is the SAP Bierman/Iddon Expires May 17, 1996 [Page 19] Draft RMON Protocol Identifiers November 17, 1995 value which maps to the child protocol. For example, a protocolDirID value of: 8.0.0.0.2.0.0.0.240 defines NetBios over LLC. Children are named as 'llc' followed by the SAP value in hexadecimal. So the above example would have been named: llc 0xf0" ADDRESS-FORMAT "The address consists of 6 octets of MAC address in network order. Source routing bits should be stripped out of the address if present." DECODING "Notice that LLC has a variable length protocol header; there are always three octets (DSAP, SSAP, control). Depending on the value of the control bits in the DSAP, SSAP and control fields there may be an additional octet of control information. LLC can be present on several different media. For 802.3 and 802.5 its presence is mandated (but see ether2 and raw802.3 encapsulations). For 802.5 there is no other link layer protocol. Notice also that the raw802.3 link layer protocol may take precedence over this one in a protocol specific manner such that it may not be possible to utilize all LSAP values if raw802.3 is also present." REFERENCE "IEEE 802.2 - [TBD] The authoritative list of LLC LSAP values is controlled by the IEEE Registration Authority: IEEE Registration Authority c/o Iris Ringel IEEE Standards Dept 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331 Phone +1 908 562 3813 Fax: +1 908 562 1571" ::= { 2 } Bierman/Iddon Expires May 17, 1996 [Page 20] Draft RMON Protocol Identifiers November 17, 1995 4.1.3. SNAP over LLC (OUI=000) Encapsulation snap PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of snap packets that didn't match -- any children of snap enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "The Sub-Network Access Protocol (SNAP) is layered on top of LLC protocol, allowing Ethernet-II protocols to be run over a media restricted to LLC." CHILDREN "Children of 'snap' are identified by Ethernet-II type values; the SNAP PID (Protocol Identifier) field is used to select the appropriate child. The entire SNAP protocol header is consumed; the child protocol is assumed to start at the next octet after the PID. Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' are the MSB and LSB of the Ethernet-II type value. For example, a protocolDirID value of: 8.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 "[TBD]" Bierman/Iddon Expires May 17, 1996 [Page 21] Draft RMON Protocol Identifiers November 17, 1995 ::= { 3 } 4.1.4. SNAP over LLC (OUI != 000) Encapsulation vsnap PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of vsnap packets that didn't match -- any children of vsnap enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "This pseudo-protocol handles all SNAP packets which do not have a zero OUI. See 'snap' above for details of those that do." CHILDREN "Children of 'vsnap' are selected by the 3 octet OUI; the PID is not parsed; child protocols are deemed to start with the first octet of the SNAP PID field, and continue to the end of the packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network order. For example, a protocolDirID value of: 8.0.0.0.4.0.1.2.3 defines the set of protocols whose OUI is 0x010203. Children are named as 'vsnap' followed by the 3 octets of the OUI as a single hexadecimal value. So the above example would be named: vsnap 0x010203" ADDRESS-FORMAT "The LLC address format is inherited by 'vsnap'. See the 'llc' protocol identifier for more details." DECODING "Same as for 'snap' except the OUI is non-zero." REFERENCE "Same as for 'snap'." ::= { 4 } Bierman/Iddon Expires May 17, 1996 [Page 22] Draft RMON Protocol Identifiers November 17, 1995 4.1.5. Raw 802.3 Encapsulation -- This really only here to support Novell's older encapsulation on -- ethernet-like LANs. Do not create children of this protocol unless -- you are sure that they cannot be handled by the more conventional link -- layers above. raw8023 PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of raw8023 packets that didn't match -- any children of raw8023 enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "This pseudo-protocol describes an 802.3 header (destination, source, length) with no LLC/802.2 header. This encapsulation violates the 802.3 specification in that the 802.2 header is mandated for 802.3 frames. The header is otherwise well formed." CHILDREN "Children of 'raw8023' are identified by the Ethernet-II type field value which they would use if running over the 'snap' or 'ether2' link layer protocols. In reality there is no such field in the packet; instead the agent decodes the header and maps it to this value in a protocol specific manner. The child protocol is deemed to start at the first octet after the 802.3 length field (i.e. in the information field). Children of 'raw8023' are encoded as [ 0.0.0.5 ], the protocol identifier for 'raw8023', followed by [ 0.0.a.b ] where 'a' and 'b' are the MSB and LSB of the Ethernet-II type. For example, a protocolDirID value of: 8.0.0.0.5.0.0.129.55 defines the IPX protocol encapsulated directly in 802.3. Children are named 'raw8023' followed by the value of the Ethernet-II type in hexadecimal. The above example would be named: raw8023 0x8137" ADDRESS-FORMAT "The address format is the same as that for 'ether2'." Bierman/Iddon Expires May 17, 1996 [Page 23] Draft RMON Protocol Identifiers November 17, 1995 DECODING "Whenever the 802.3 header indicates LLC a set of protocol specific tests needs to be applied to determine whether this is a 'raw8023' packet or a true 802.2 packet. The nature of these tests depends on the active child protocols for 'raw8023' and is beyond the scope of this document." REFERENCE "None - this is a pseudo-protocol." ::= { 5 } 4.2. L3 Protocol Identifiers Network layer protocol identifier macros contain additional information about the network layer, and (if present) is found immediately following an L2 layer-identifier in a protocol identifier. The ProtocolDirParameters supported at the network layer are 'countsFragments(0)', 'others(1)', and 'tracksSessions(2). 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, and therefore limit which tables the indicated protocol can be present (e.g. protocolDistribution, nlHost, nlMatrix).. The following protocol-identifier macro declarations are given for example purposes only. They are not intended to constitute an exhaustive list or an authoritative source for any of the protocol information given. 4.2.1. IP ip PROTOCOL-IDENTIFIER PARAMETERS { countsFragments(0), -- This parameter applies to all child -- protocols. others(1) -- The count of ip packets that didn't match -- any children of ip enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), Bierman/Iddon Expires May 17, 1996 [Page 24] Draft RMON Protocol Identifiers November 17, 1995 addressRecognitionCapable(1) } DESCRIPTION "The protocol identifiers for IP. " CHILDREN "Children of IP are defined by the value in the Protocol field, 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 are named 'ip a' where a is the protocol field value (in decimal)." 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.: ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0 ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 " REFERENCE "RFC 791; The following URL defines the authoritative repository for the PROTOCOL NUMBERS Table: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers" ::= { ether2 0x0800, llc 0x08, snap 0x0800, ip 4, ip 94 } 4.2.1.1. Children of IP Bierman/Iddon Expires May 17, 1996 [Page 25] Draft RMON Protocol Identifiers November 17, 1995 4.2.1.1.1. ICMP icmp PROTOCOL-IDENTIFIER PARAMETERS {} ATTRIBUTES {} DESCRIPTION "Internet Message Control Protocol." REFERENCE "RFC-792" ::= { ip 1 } 4.2.1.1.2. TCP tcp PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of tcp packets that didn't match -- any children of tcp enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0) } DESCRIPTION "Transmission Control Protocol." CHILDREN "Children of TCP are identified by the 16 bit Destination Port value as specified in RFC 793." REFERENCE "RFC 793; The following URL defines the authoritative repository for reserved and registered TCP port values: ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" ::= { ip 6 } 4.2.1.1.3. UDP udp PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of udp packets that didn't match -- any children of udp enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0) } Bierman/Iddon Expires May 17, 1996 [Page 26] Draft RMON Protocol Identifiers November 17, 1995 DESCRIPTION "User Datagram Protocol." CHILDREN "Children of UDP are identified by the 16 bit Destination Port value as specified in RFC 768." REFERENCE "RFC 768; The following URL defines the authoritative repository for reserved and registered UDP port values: ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" ::= { ip 17 } 4.2.1.1.3.1. Children of UDP Note that some of the following protocols can be encapsulated in protocols other than UDP. The assignment section of each protocol- identifier macro lists any additional encapsulations. 4.2.1.1.3.1. SNMP snmp PROTOCOL-IDENTIFIER PARAMETERS {} ATTRIBUTES {} DESCRIPTION "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 protocol versions. Does not include SNMP trap packets." REFERENCE "SNMPv2: RFCs 1441 - 1452; SNMPv1: RFC 1155, RFC 1157; SNMP over IPX: RFC 1420; SNMP over AppleTalk: RFC 1419;" ::= { udp 161, ipx 161 } 4.2.1.1.3.1. SNMPTRAP snmptrap PROTOCOL-IDENTIFIER PARAMETERS {} ATTRIBUTES {} DESCRIPTION "Simple Network Management Protocol Trap Port." REFERENCE Bierman/Iddon Expires May 17, 1996 [Page 27] Draft RMON Protocol Identifiers November 17, 1995 "SNMPv2: RFCs 1441 - 1452; SNMPv1: RFC 1155, RFC 1157; SNMP over IPX: RFC 1420; SNMP over AppleTalk: RFC 1419;" ::= { udp 162, ipx 162 } 4.2.1.1.3.1. TFTP tftp PROTOCOL-IDENTIFIER PARAMETERS { tracksSessions(2) } ATTRIBUTES {} DESCRIPTION "Trivial File Transfer Protocol; Only the first packet of each TFTP transaction will be sent to port 69. If the tracksSessions attribute is set, then packets for each TFTP transaction will be attributed to tftp, instead of the unregistered port numbers that will be encoded in subsequent packets." REFERENCE "RFC 1350; TFTP Option Extension (RFC 1782) TFTP Blocksize Option (RFC 1783) TFTP Timeout Interval and Transfer Size Options (RFC 1784) TFTP Option Negotiation Analysis (RFC 1785)" ::= { udp 69 } 4.2.2. IPX ipx PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of ipx packets that didn't match -- any children of ipx enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "Novell IPX" CHILDREN "Children of IPX are defined by the 16 bit value of the Bierman/Iddon Expires May 17, 1996 [Page 28] Draft RMON Protocol Identifiers November 17, 1995 Destination Socket field. The value is encoded into an octet string as [ 0.0.a.b ], where 'a' and 'b' are the network byte order encodings of the MSB and LSB of the destination socket field." ADDRESS-FORMAT "4 bytes of Network number followed by the 6 bytes Host address each in network byte order". DECODING "" REFERENCE "Novell [TBD]" ::= { ether2 0x8137, -- 0.0.129.55 llc 0xe0e003, -- 0.224.224.3 snap 0x8137, -- 0.0.129.55 raw8023 0x8137 -- 0.0.129.55 } 4.2.3. ARP arp PROTOCOL-IDENTIFIER PARAMETERS {} ATTRIBUTES {} DESCRIPTION "An 802.3 header followed immediately by a payload (i.e. no TYPE field)." REFERENCE "RFC 826" ::= { ether2 0x806, -- [ 0.0.8.6 ] snap 0x806 } 4.2.4. IDP idp PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of idp packets that didn't match -- any children of idp enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } Bierman/Iddon Expires May 17, 1996 [Page 29] Draft RMON Protocol Identifiers November 17, 1995 DESCRIPTION "Xerox IDP" CHILDREN "Children of IDP are defined by the 8 bit value of the Packet type field. The value is encoded into an octet string as [ 0.0.0.a ], where 'a' is the value of the packet type field in network byte order. ADDRESS-FORMAT "4 bytes of Network number followed by the 6 bytes Host address each in network byte order". REFERENCE "Xerox Corporation, Document XNSS 028112, 1981" ::= { ether2 0x600, -- [ 0.0.6.0 ] snap 0x600 } 4.2.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 ] snap 0x80F3 } 4.2.6. Appletalk atalk PROTOCOL-IDENTIFIER PARAMETERS { others(1) -- The count of ether2 packets that didn't match -- any children of ether2 enabled in the protocolDirectory } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "AppleTalk Protocol." Bierman/Iddon Expires May 17, 1996 [Page 30] Draft RMON Protocol Identifiers November 17, 1995 CHILDREN "Children of ATALK are defined by the 8 bit value of the DDP type field. The value is encoded into an octet string as [ 0.0.0.a ], where 'a' is the value of the DDP type field in network byte order. ADDRESS-FORMAT "2 bytes of Network number followed by 1 byte of node id each in network byte order". REFERENCE "AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A." ::= { ether2 0x809b, -- [ 0.0.128.155 ] vsnap 0x809b } Bierman/Iddon Expires May 17, 1996 [Page 31] Draft RMON Protocol Identifiers November 17, 1995 5. Acknowledgements This document was produced by the IETF RMONMIB Working Group. The authors wish to thank the following people for their contributions to this document: Anil Singhal Frontier Software Development, Inc. anil@frontier.com Jeanne Haney Coronet Systems jeanne@coronet.com Dan Hansen Network General Corp. danh@ngc.com Bierman/Iddon Expires May 17, 1996 [Page 32] Draft RMON Protocol Identifiers November 17, 1995 6. References [RFC1212] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [RFC1442] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [RFC1445] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [RFC1448] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC1757] S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie Mellon University, February 1995. [RFC1800] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 1800, IAB, July 1995. [RMON2] S. Waldbusser, "Remote Network Monitoring MIB Version 2", draft- Bierman/Iddon Expires May 17, 1996 [Page 33] Draft RMON Protocol Identifiers November 17, 1995 ietf-rmonmib-rmon2-02.txt, International Network Services, October 1995. Bierman/Iddon Expires May 17, 1996 [Page 34] Draft RMON Protocol Identifiers November 17, 1995 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Andy Bierman Bierman Consulting 1200 Sagamore Lane Ventura, CA 93001 Phone: 805-648-2028 Email: abierman@west.net Robin Iddon AXON Networks, Inc. [TBD] Phone: [TBD] Email: robini@axon.com Bierman/Iddon Expires May 17, 1996 [Page 35] Draft RMON Protocol Identifiers November 17, 1995 Table of Contents 1 Introduction .................................................... 2 1.1 The SNMPv2 Network Management Framework ....................... 2 1.1.1 Object Definitions .......................................... 2 2 Overview ........................................................ 3 2.1 Terms ......................................................... 3 2.2 Relationship to the Remote Network Monitoring MIB ............. 5 2.3 Relationship to the Other MIBs ................................ 5 3 Protocol Identifier Encoding .................................... 6 3.1 ProtocolDirTable INDEX Format Examples ........................ 8 3.2 Protocol Identifier Macro Format .............................. 9 3.2.1 Mapping of the Protocol Name ................................ 9 3.2.2 Mapping of the PARAMETERS Clause ............................ 10 3.2.2.1 Mapping of the 'countsFragments(0)' BIT ................... 11 3.2.2.2 Mapping of the 'others(1)' BIT ............................ 12 3.2.2.2.1 Relationship to the protocolDirTable .................... 12 3.2.2.3 Mapping of the 'tracksSessions(2)' BIT .................... 13 3.2.3 Mapping of the ATTRIBUTES Clause ............................ 13 3.2.4 Mapping of the DESCRIPTION Clause ........................... 14 3.2.5 Mapping of the CHILDREN Clause .............................. 14 3.2.6 Mapping of the ADDRESS-FORMAT Clause ........................ 15 3.2.7 Mapping of the DECODING Clause .............................. 15 3.2.8 Mapping of the REFERENCE Clause ............................. 15 3.2.9 Evaluating a Protocol-Identifier INDEX ...................... 16 4 Protocol Identifier Macro Examples .............................. 17 4.1 L2 Protocol Identifiers ....................................... 17 4.1.1 Ether2 Encapsulation ........................................ 18 4.1.2 LLC Encapsulation ........................................... 19 4.1.3 SNAP over LLC (OUI=000) Encapsulation ....................... 21 4.1.4 SNAP over LLC (OUI != 000) Encapsulation .................... 22 4.1.5 Raw 802.3 Encapsulation ..................................... 23 4.2 L3 Protocol Identifiers ....................................... 24 4.2.1 IP .......................................................... 24 4.2.1.1 Children of IP ............................................ 25 4.2.1.1.1 ICMP .................................................... 26 4.2.1.1.2 TCP ..................................................... 26 4.2.1.1.3 UDP ..................................................... 26 4.2.1.1.3.1 Children of UDP ....................................... 27 4.2.1.1.3.1 SNMP .................................................. 27 4.2.1.1.3.1 SNMPTRAP .............................................. 27 4.2.1.1.3.1 TFTP .................................................. 28 4.2.2 IPX ......................................................... 28 4.2.3 ARP ......................................................... 29 Bierman/Iddon Expires May 17, 1996 [Page 36] Draft RMON Protocol Identifiers November 17, 1995 4.2.4 IDP ......................................................... 29 4.2.5 Appletalk ARP ............................................... 30 4.2.6 Appletalk ................................................... 30 5 Acknowledgements ................................................ 32 6 References ...................................................... 33 7 Security Considerations ......................................... 35 8 Authors' Addresses .............................................. 35 Bierman/Iddon Expires May 17, 1996 [Page 37]