From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2074.txt | 2411 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2411 insertions(+) create mode 100644 doc/rfc/rfc2074.txt (limited to 'doc/rfc/rfc2074.txt') diff --git a/doc/rfc/rfc2074.txt b/doc/rfc/rfc2074.txt new file mode 100644 index 0000000..7d41e8b --- /dev/null +++ b/doc/rfc/rfc2074.txt @@ -0,0 +1,2411 @@ + + + + + + +Network Working Group A. Bierman +Request for Comments: 2074 Cisco Systems +Category: Standards Track R. Iddon + AXON Networks,Inc. + January 1997 + + + Remote Network Monitoring MIB Protocol Identifiers + +Status of this Memo + + 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. + +Table of Contents + +1 Introduction .................................................... 3 +2 The SNMP Network Management Framework ........................... 3 +2.1 Object Definitions ............................................ 3 +3 Overview ........................................................ 3 +3.1 Terms ......................................................... 4 +3.2 Relationship to the Remote Network Monitoring MIB ............. 6 +3.3 Relationship to the Other MIBs ................................ 6 +4 Protocol Identifier Encoding .................................... 7 +4.1 ProtocolDirTable INDEX Format Examples ........................ 9 +4.2 Protocol Identifier Macro Format .............................. 10 +4.2.1 Mapping of the Protocol Name ................................ 12 +4.2.2 Mapping of the VARIANT-OF Clause ............................ 13 +4.2.3 Mapping of the PARAMETERS Clause ............................ 13 +4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 14 +4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 15 +4.2.4 Mapping of the ATTRIBUTES Clause ............................ 15 +4.2.5 Mapping of the DESCRIPTION Clause ........................... 15 +4.2.6 Mapping of the CHILDREN Clause .............................. 16 +4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 16 +4.2.8 Mapping of the DECODING Clause .............................. 16 +4.2.9 Mapping of the REFERENCE Clause ............................. 17 +4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 17 +5 Protocol Identifier Macros ...................................... 18 +5.1 Base Identifier Encoding ...................................... 18 +5.1.1 Protocol Identifier Functions ............................... 19 +5.1.1.1 Function 0: No-op ......................................... 19 +5.1.1.2 Function 1: Protocol Wildcard Function .................... 19 +5.2 Base Layer Protocol Identifiers ............................... 20 +5.2.1 Ether2 Encapsulation ........................................ 21 + + + +Bierman & Iddon Standards Track [Page 1] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.2.2 LLC Encapsulation ........................................... 22 +5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 23 +5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 24 +5.2.5 IANA Assigned Protocols ..................................... 25 +5.2.5.1 IANA Assigned Protocol Identifiers ........................ 27 +5.3 L3: Children of Base Protocol Identifiers ..................... 27 +5.3.1 IP .......................................................... 28 +5.3.2 IPX ......................................................... 29 +5.3.3 ARP ......................................................... 30 +5.3.4 IDP ......................................................... 30 +5.3.5 AppleTalk ARP ............................................... 31 +5.3.6 AppleTalk ................................................... 31 +5.4 L4: Children of L3 Protocols .................................. 32 +5.4.1 ICMP ........................................................ 32 +5.4.2 TCP ......................................................... 32 +5.4.3 UDP ......................................................... 33 +5.5 L5: Application Layer Protocols ............................... 33 +5.5.1 FTP ......................................................... 33 +5.5.1.1 FTP-DATA .................................................. 33 +5.5.1.2 FTP Control ............................................... 34 +5.5.2 Telnet ...................................................... 34 +5.5.3 SMTP ........................................................ 34 +5.5.4 DNS ......................................................... 35 +5.5.5 BOOTP ....................................................... 35 +5.5.5.1 Bootstrap Server Protocol ................................. 35 +5.5.5.2 Bootstrap Client Protocol ................................. 35 +5.5.6 TFTP ........................................................ 36 +5.5.7 HTTP ........................................................ 36 +5.5.8 POP3 ........................................................ 36 +5.5.9 SUNRPC ...................................................... 37 +5.5.10 NFS ........................................................ 38 +5.5.11 SNMP ....................................................... 38 +5.5.11.1 SNMP Request/Response .................................... 38 +5.5.11.2 SNMP Trap ................................................ 39 +6 Acknowledgements ................................................ 39 +7 References ...................................................... 40 +8 Security Considerations ......................................... 43 +9 Authors' Addresses .............................................. 43 + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 2] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +1. Introduction + + This memo defines an experimental portion of the Management + Information Base (MIB) for use with network management protocols in + the Internet community. In particular, it describes the algorithms + required to identify different protocol encapsulations managed with + the Remote Network Monitoring MIB Version 2 [RMON2]. Although related + to the original Remote Network Monitoring MIB [RFC1757], this + document refers only to objects found in the RMON-2 MIB. + +2. The SNMP Network Management Framework + + The SNMP Network Management Framework presently consists of three + major components. They are: + +o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for + describing and naming objects for the purpose of management. + +o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed + objects for the Internet suite of protocols. + +o the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], + - the protocol for accessing managed information. + + Textual conventions are defined in RFC 1903 [RFC1903], and + conformance statements are defined in RFC 1904 [RFC1904]. + + The Framework permits new objects to be defined for the purpose of + experimentation and evaluation. + +2.1. Object Definitions + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the subset of Abstract Syntax Notation One (ASN.1) + defined in the SMI. In particular, each object type is named by an + OBJECT IDENTIFIER, an administratively assigned name. The object + type together with an object instance serves to uniquely identify a + specific instantiation of the object. For human convenience, we + often use a textual string, termed the descriptor, to refer to the + object type. + +3. Overview + + The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to + globally identify individual protocol encapsulations in the + protocolDirTable. + + + + +Bierman & Iddon Standards Track [Page 3] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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. + +3.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 string fragment identifying a particular + protocol encapsulation layer. This string is exactly four octets, + (except for the 'vsnap' base-layer identifier, which is exactly + eight octets) encoded in network byte order. A particular protocol + encapsulation can be identified by starting with a base layer + encapsulation (see the 'Base Protocol Identifiers' section for more + detail), and following the encoding rules specified in the CHILDREN + clause and assignment section for that layer. Then repeat for each + identified layer in the encapsulation. (See section 4.2.10 + 'Evaluating a Protocol-Identifier INDEX' for more detail.) + +protocol: + A particular protocol layer, as specified by encoding rules in this + document. Usually refers to a single layer in a given + encapsulation. Note that this term is sometimes used in the RMON-2 + MIB [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-identifier string is composed of one or more layer- + identifiers. + + + + + + + + + +Bierman & Iddon Standards Track [Page 4] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +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-variant-identifier macro: + A group of formatted text describing a particular protocol layer, + as used within the RMON-2 MIB [RMON2]. This protocol is a variant + of a well known encapsulation that may be present in the + protocolDirTable. This macro is used to document the IANA + assigned protocols, which are needed to identify protocols which + cannot be practically identified by examination of 'appropriate + network traffic' (e.g. the packets which carry them). All other + protocols (which can be identified by examination of appropriate + network traffic) should be documented using the protocol-identifier + macro. A protocol-variant-identifier is documented using the + protocol-variant version of the protocol-identifier macro. + +protocol-parameter: + A single octet, corresponding to a specific layer-identifier in the + protocol-identifier. This octet is a bit-mask indicating special + functions or capabilities that this agent is providing for the + corresponding protocol. + +protocol-parameters string: + An octet string, which contains one protocol-parameter for each + layer-identifier in the protocol-identifier. See the section + '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 in section 7.7 of RFC 1902 [RFC1902]. + + + + + + +Bierman & Iddon Standards Track [Page 5] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +pseudo-protocol: + A convention or algorithm used only within this document for the + purpose of encoding protocol-identifier strings. + +3.2. Relationship to the Remote Network Monitoring MIB + + This document is intended to identify possible string values for the + OCTET STRING objects protocolDirID and protocolDirParameters. Tables + in the new Protocol Distribution, Host, and Matrix groups use a local + INTEGER INDEX, in order to remain unaffected by changes in this + document. Only the protocolDirTable uses the strings (protocolDirID + and protocolDirParameters) described in this document. + + This document is not intended to limit the protocols that may be + identified for counting in the RMON-2 MIB. Many protocol + encapsulations, not explicitly identified in this document, may be + present in an actual implementation of the protocolDirTable. Also, + implementations of the protocolDirTable may not include all the + protocols identified in the example section below. + + 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. + +3.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 Standards Track [Page 6] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +4. Protocol Identifier Encoding + + The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID + and protocolDirParameters. To encode the table index, each variable- + length string is converted to an OBJECT IDENTIFIER fragment, + according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. + Then the index fragments are simply concatenated. (Refer to figures + 1a - 1d below for more detail.) + + The first OCTET STRING (protocolDirID) is composed of one or more 4- + octet "layer-identifiers". The entire string uniquely identifies a + particular protocol encapsulation tree. The second OCTET STRING, + (protocolDirParameters) which contains a corresponding number of 1- + octet protocol-specific parameters, one for each 4-octet layer- + identifier in the first string. + + A protocol layer is normally identified by a single 32-bit value. + Each layer-identifier is encoded in the ProtocolDirID OCTET STRING + INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent + each byte of the 32-bit value in network byte order. If a particular + protocol layer cannot be encoded into 32 bits, (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 ! | + +---+--------------------------+---+---------------+ + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 7] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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. + + + + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 8] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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. + +4.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 Standards Track [Page 9] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + -- 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 + +4.2. Protocol Identifier Macro Format + + The following example is meant to introduce the protocol-identifier + macro. (The syntax is not quite ASN.1.) This macro is used to + represent both protocols and protocol-variants. + + If the 'VariantOfPart' component of the macro is present, then the + macro represents a protocol-variant instead of a protocol. A + protocol- variant-identifier is used only for IANA assigned + protocols, enumerated under the 'ianaAssigned' base-layer. + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 10] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 + + + +Bierman & Iddon Standards Track [Page 11] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 + +4.2.1. Mapping of the Protocol Name + + The 'PIMacroName' value should be a lower-case ASCII string, and + contain the name or acronym identifying the protocol. NMS + applications may treat protocol names as case-insensitive strings, + and agent implementations must make sure the protocolDirTable does + not contain any instances of the protocolDirDescr object which differ + only in the case of one of more letters (if the identifiers are + intended to represent different protocols). + + It is possible that different encapsulations of the same protocol + (which are represented by different entries in the protocolDirTable) + will be assigned the same protocol name. + + + + + +Bierman & Iddon Standards Track [Page 12] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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. + +4.2.2. Mapping of the VARIANT-OF Clause + + This clause is present for IANA assigned protocols only. It + identifies the protocol-identifier macro that most closely represents + this particular protocol, and is known as the "reference protocol". + (A protocol-identifier macro must exist for the reference protocol.) + When 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. + +4.2.3. Mapping of the PARAMETERS Clause + + The protocolDirParameters object provides an NMS the ability to turn + on and off expensive probe resources. An agent may support a given + parameter all the time, not at all, or subject to current resource + load. + + The PARAMETERS clause is a list of bit definitions which can be + directly encoded into the associated ProtocolDirParameters octet in + network byte order. Zero or more bit definitions may be present. Only + bits 0-7 are valid encoding values. This clause defines the entire + BIT set allowed for a given protocol. A conforming agent may choose + to implement a subset of zero or more of these PARAMETERS. + + + +Bierman & Iddon Standards Track [Page 13] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + By convention, the following common bit definitions are used by + different protocols. These bit positions must not be used for other + parameters. They should be reserved if not used by a given protocol. + Bits are encoded in network-byte order. + + Table 3.1 Reserved PARAMETERS Bits + ------------------------------------ + +Bit Name Description +--------------------------------------------------------------------- +0 countsFragments higher-layer protocols encapsulated within + this protocol will be counted correctly even + if this protocol fragments the upper layers + into multiple packets. +1 tracksSessions correctly attributes all packets of a protocol + which starts sessions on well known ports or + sockets and then transfers them to dynamically + assigned ports or sockets thereafter (e.g. TFTP). + + The PARAMETERS clause must be present in all protocol-identifier + macro declarations, but may be equal to zero (empty). Note that an + NMS must determine if a given PARAMETER bit is supported by + attempting to create the desired protocolDirEntry The associated + ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not + exist. + +4.2.3.1. Mapping of the 'countsFragments(0)' BIT + + This bit indicates whether the probe is correctly attributing all + fragmented packets of the specified protocol, even if individual + frames carrying this protocol cannot be identified as such. Note + that the probe is not required to actually present any re-assembled + datagrams (for address-analysis, filtering, or any other purpose) to + the NMS. + + This bit may only be set in a protocolDirParameters octet which + corresponds to a protocol that supports fragmentation and reassembly + in some form. Note that TCP packets are not considered 'fragmented- + streams' and so TCP is not eligible. + + This bit may be set in at most one protocolDirParameters octet within + a protocolDirTable INDEX. + + + + + + + + + +Bierman & Iddon Standards Track [Page 14] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +4.2.3.2. Mapping of the 'tracksSessions(1)' BIT + + The 'tracksSessions(1)' bit indicates whether frames which are part + of remapped-sessions (e.g. TFTP download sessions) are correctly + counted by the probe. For such a protocol, the probe must usually + analyze all packets received on the indicated interface, and maintain + some state information, (e.g. the remapped UDP port number for TFTP). + + The semantics of the 'tracksSessions' parameter are independent of + the other protocolDirParameters definitions, so this parameter may be + combined with any other legal parameter configurations. + +4.2.4. Mapping of the ATTRIBUTES Clause + + The protocolDirType object provides an NMS with an indication of a + probe's capabilities for decoding a given protocol, or the general + attributes of the particular protocol. + + The ATTRIBUTES clause is a list of bit definitions which are encoded + into the associated instance of ProtocolDirType. The BIT definitions + are specified in the SYNTAX clause of the protocolDirType MIB object. + + Table 3.2 Reserved ATTRIBUTES Bits + ------------------------------------ + + Bit Name Description + --------------------------------------------------------------------- + 0 hasChildren indicates that there may be children of + this protocol defined in the protocolDirTable + (by either the agent or the manager). + 1 addressRecognitionCapable + indicates that this protocol can be used + to generate host and matrix table entries. + + The ATTRIBUTES clause must be present in all protocol-identifier + macro declarations, but may be empty. + +4.2.5. 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. + + + + + +Bierman & Iddon Standards Track [Page 15] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +4.2.6. Mapping of the CHILDREN Clause + + The CHILDREN clause provides a description of child protocols for + protocols which support them. It has three sub-sections: + + - Details on the field(s)/value(s) used to select the child protocol, + and how that selection process is performed + + - Details on how the value(s) are encoded in the protocol identifier + octet string + + - Details on how child protocols are named with respect to their + parent protocol label(s) + + The CHILDREN clause must be present in all protocol-identifier macro + declarations in which the 'hasChildren(0)' BIT is set in the + ATTRIBUTES clause. + +4.2.7. Mapping of the ADDRESS-FORMAT Clause + + The ADDRESS-FORMAT clause provides a description of the OCTET-STRING + format(s) used when encoding addresses. + + This clause must be present in all protocol-identifier macro + declarations in which the 'addressRecognitionCapable(1)' BIT is set + in the ATTRIBUTES clause. + +4.2.8. Mapping of the DECODING Clause + + The DECODING clause provides a description of the decoding procedure + for the specified protocol. It contains useful decoding hints for the + implementor, but should not over-replicate information in documents + cited in the REFERENCE clause. It might contain a complete + description of any decoding information required. + + For 'extensible' protocols ('hasChildren(0)' BIT set) this includes + offset and type information for the field(s) used for child selection + as well as information on determining the start of the child + protocol. + + For 'addressRecognitionCapable' protocols this includes offset and + type information for the field(s) used to generate addresses. + + The DECODING clause is optional, and may be omitted if the REFERENCE + clause contains pointers to decoding information for the specified + protocol. + + + + + +Bierman & Iddon Standards Track [Page 16] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +4.2.9. Mapping of the REFERENCE Clause + + If a publicly available reference document exists for this protocol + it should be listed here. Typically this will be a URL if possible; + if not then it will be the name and address of the controlling body. + + The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the + amount of information which may currently be obtained from an + 'authoritative' document, such as the Assigned Numbers document + [RFC1700]. Any duplication or paraphrasing of information should be + brief and consistent with the authoritative document. + + The REFERENCE clause is optional, but should be implemented if an + authoritative reference exists for the protocol (especially for + standard protocols). + +4.2.10. Evaluating a Protocol-Identifier INDEX + + The following evaluation is done after protocolDirTable INDEX value + has been converted into two OCTET STRINGs according to the INDEX + encoding rules specified in the SMI [RFC1902]. + + Protocol-identifiers are evaluated left to right, starting with the + protocolDirID, which length should be evenly divisible by four. The + protocolDirParameters length should be exactly one quarter of the + protocolDirID string length. + + Protocol-identifier parsing starts with the base layer identifier, + which must be present, and continues for one or more upper layer + identifiers, until all OCTETs of the protocolDirID have been used. + Layers may not be skipped, so identifiers such as 'SNMP over IP' or + 'TCP over 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'), + + + +Bierman & Iddon Standards Track [Page 17] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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.). + +5. Protocol Identifier Macros + + The following PROTOCOL IDENTIFIER macros can be used to construct + protocolDirID and protocolDirParameters strings. + + The sections defining protocol examples are intended to grow over + subsequent releases. Minimal protocol support is included at this + time. (Refer to section 3.2 for details on the protocol macro update + procedure.) + + An identifier is encoded by constructing the base-identifier, then + adding one layer-identifier for each encapsulated protocol. + +5.1. Base Identifier Encoding + + The first layer encapsulation is called the base identifier and it + contains optional protocol-function information and the base layer + (e.g. MAC layer) enumeration value used in this protocol identifier. + + The base identifier is encoded as four octets as shown in figure 2. + + Fig. 2 + base-identifier format + +---+---+---+---+ + | | | | | + | f |op1|op2| m | + | | | | | + +---+---+---+---+ octet + | 1 | 1 | 1 | 1 | count + + The first octet ('f') is the special function code, found in table + 4.1. The next two octets ('op1' and 'op2') are operands for the + indicated function. If not used, an operand must be set to zero. The + last octet, 'm', is the enumerated value for a particular base layer + encapsulation, found in table 4.2. All four octets are encoded in + network-byte-order. + + + + + +Bierman & Iddon Standards Track [Page 18] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.1.1. Protocol Identifier Functions + + The base layer identifier contains information about any special + functions to perform during collections of this protocol, as well as + the base layer encapsulation identifier. + + The first three octets of the identifier contain the function code + and two optional operands. The fourth octet contains the particular + base layer encapsulation used in this protocol (fig. 2). + + Table 4.1 Assigned Protocol Identifier Functions + ------------------------------------------------- + + Function ID Param1 Param2 + ---------------------------------------------------- + none 0 not used (0) not used (0) + wildcard 1 not used (0) not used (0) + +5.1.1.1. Function 0: No-op + + If the function ID field (1st octet) is equal to zero, the the 'op1' + and 'op2' fields (2nd and 3rd octets) must also be equal to zero. + This special value indicates that no functions are applied to the + protocol identifier encoded in the remaining octets. The identifier + represents a normal protocol encapsulation. + +5.1.1.2. Function 1: Protocol Wildcard Function + + The wildcard function (function-ID = 1), is used to aggregate + counters, by using a single protocol value to indicate potentially + many base layer encapsulations of a particular network layer + protocol. A protocolDirEntry of this type will match any base-layer + encapsulation of the same 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. + + + + + + + + + +Bierman & Iddon Standards Track [Page 19] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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. + +5.2. Base Layer Protocol Identifiers + + The base layer is mandatory, and defines the base encapsulation of + the packet and any special functions for this identifier. + + There are no suggested protocolDirParameters bits for the base layer. + + The suggested ProtocolDirDescr field for the base layer is given by + the corresponding "Name" field in the table 4.1 below. However, + implementations are only required to use the appropriate integer + identifier values. + + For most base layer protocols, the protocolDirType field should + contain bits set for the 'hasChildren(0)' and + 'addressRecognitionCapable(1)' attributes. However, the special + 'ianaAssigned' base layer should have no parameter or attribute bits + set. + + By design, only 255 different base layer encapsulations are + supported. There are five base encapsulation values defined at this + time. New base encapsulations (e.g. for new media types) are expected + to be added over time. + + Table 4.2 Base Layer Encoding Values + -------------------------------------- + + Name ID + ------------------ + ether2 1 + llc 2 + snap 3 + vsnap 4 + ianaAssigned 5 + + + + + + + + + + +Bierman & Iddon Standards Track [Page 20] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.2.1. Ether2 Encapsulation + +ether2 PROTOCOL-IDENTIFIER + PARAMETERS { } + 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-fragment value of: + 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. + + 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 } + + + + + + + + + + +Bierman & Iddon Standards Track [Page 21] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.2.2. LLC Encapsulation + +llc PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "The LLC (802.2) protocol." + CHILDREN + "The LLC SSAP and DSAP (Source/Dest Service Access Points) are + used to select child protocols. Each of these is one octet long, + although the least significant bit is a control bit and should be + masked out in most situations. Typically SSAP and DSAP (once + masked) are the same for a given protocol - each end implicitly + knows whether it is the server or client in a client/server + protocol. This is only a convention, however, and it is possible + for them to be different. The SSAP is matched against child + protocols first. If none is found then the DSAP is matched + instead. The child protocol is deemed to start at the first + octet after the LLC control field(s). + + Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol + identifier component for LLC followed by [ 0.0.0.a ] where 'a' is + the SAP value which maps to the child protocol. For example, a + protocolDirID-fragment value of: + 0.0.0.2.0.0.0.240 + + defines NetBios over LLC. + + Children are named as 'llc' followed by the SAP value in + hexadecimal. So the above example would have been named: + llc 0xf0" + ADDRESS-FORMAT + "The address consists of 6 octets of MAC address in network + order. Source routing bits should be stripped out of the address + if present." + DECODING + "Notice that LLC has a variable length protocol header; there are + always three octets (DSAP, SSAP, control). Depending on the + value of the control bits in the DSAP, SSAP and control fields + there may be an additional octet of control information. + + LLC can be present on several different media. For 802.3 and + 802.5 its presence is mandated (but see ether2 and raw802.3 + encapsulations). For 802.5 there is no other link layer + protocol. + + + +Bierman & Iddon Standards Track [Page 22] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 } + +5.2.3. SNAP over LLC (OUI=000) Encapsulation + +snap PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "The Sub-Network Access Protocol (SNAP) is layered on top of LLC + protocol, allowing Ethernet-II protocols to be run over a media + restricted to LLC." + CHILDREN + "Children of 'snap' are identified by Ethernet-II type values; + the SNAP PID (Protocol Identifier) field is used to select the + appropriate child. The entire SNAP protocol header is consumed; + the child protocol is assumed to start at the next octet after + the PID. + + Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol + identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' + are the MSB and LSB of the Ethernet-II type value. For example, + a protocolDirID-fragment value of: + 0.0.0.3.0.0.8.0 + + defines the IP/SNAP protocol. + + Children of this protocol are named 'snap' followed by the + Ethernet-II type value in hexadecimal. The above example would + be named: + + snap 0x0800" + + + +Bierman & Iddon Standards Track [Page 23] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 } + +5.2.4. SNAP over LLC (OUI != 000) Encapsulation + +vsnap PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "This pseudo-protocol handles all SNAP packets which do not have + a zero OUI. See 'snap' above for details of those that 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.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. + + + + + +Bierman & Iddon Standards Track [Page 24] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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() ', where the + '' field is represented as 3 octets in hexadecimal notation + or the ASCII string associated with the OUI value. The + 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 } + +5.2.5. IANA Assigned Protocols + +ianaAssigned PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "This branch contains protocols which do not conform easily to + the hierarchical format utilized in the other link layer + branches. Usually, such a protocol 'almost' conforms to a + particular 'well-known' identifier format, but additional + criteria are used (e.g. configuration-based), making protocol + identification difficult or impossible by examination of + appropriate network traffic. preventing the any 'well-known' + protocol-identifier macro from being used. + + + + + + + +Bierman & Iddon Standards Track [Page 25] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 } + + + + + + + +Bierman & Iddon Standards Track [Page 26] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.2.5.1. IANA Assigned Protocol Identifiers + + The following protocol-variant-identifier macro declarations are used + to identify the RMONMIB IANA assigned protocols in a proprietary way, + by simple enumeration. Note that an additional four-octet layer + identifier may be used for some enumerations (as with the 'vsnap' + base-layer identifier). Refer to the 'CHILDREN' clause in the + protocol-identifier macro for a particular protocol to determine the + number of octets in the 'ianaAssigned' layer-identifier. + +ipxOverRaw8023 PROTOCOL-IDENTIFIER + VARIANT-OF "ipx" + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "This pseudo-protocol describes an encapsulation of IPX over + 802.3, without a type field. + + Refer to the macro for IPX for additional information about this + protocol." + DECODING + "Whenever the 802.3 header indicates LLC a set of protocol + specific tests needs to be applied to determine whether this is a + 'raw8023' packet or a true 802.2 packet. The nature of these + tests depends on the active child protocols for 'raw8023' and is + beyond the scope of this document." + ::= { ianaAssigned 1 } + +5.3. L3: Children of Base Protocol Identifiers + + Network layer protocol identifier macros contain additional + information about the network layer, and is found immediately + following a base layer-identifier in a protocol identifier. + + The ProtocolDirParameters supported at the network layer are + 'countsFragments(0)', and 'tracksSessions(1). An agent may choose to + implement a subset of these parameters. + + The protocol-name should be used for the ProtocolDirDescr field. The + ProtocolDirType ATTRIBUTES used at the network layer are + 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may + choose to implement a subset of these attributes for each protocol, + and therefore limit which tables the indicated protocol can be + present (e.g. protocol distribution, host, and matrix tables).. + + The following protocol-identifier macro declarations are given for + example purposes only. They are not intended to constitute an + exhaustive list or an authoritative source for any of the protocol + + + +Bierman & Iddon Standards Track [Page 27] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + information given. However, any protocol that can encapsulate other + protocols must be documented here in order to encode the children + identifiers into protocolDirID strings. Leaf protocols should be + documented as well, but an implementation can identify a leaf + protocol even if it isn't listed here (as long as the parent is + documented). + +5.3.1. IP + +ip PROTOCOL-IDENTIFIER + PARAMETERS { + countsFragments(0) -- This parameter applies to all child + -- protocols. + } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "The protocol identifiers for the Internet Protocol (IP). Note + that IP may be encapsulated within itself, so more than one of + the following identifiers may be present in a particular + protocolDirID string." + CHILDREN + "Children of 'ip' are selected by the value in the Protocol field + (one octet), as defined in the PROTOCOL NUMBERS table within the + Assigned Numbers Document. + + The value of the Protocol field is encoded in an octet string as + [ 0.0.0.a ], where 'a' is the protocol field . + + Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a' + where 'a' is the protocol field value. For example, a + protocolDirID-fragment value of: + 0.0.0.1.0.0.8.0.0.0.0.1 + + defines an encapsulation of ICMP (ether2.ip.icmp)" + ADDRESS-FORMAT + "4 octets of the IP address, in network byte order. Each ip + packet contains two addresses, the source address and the + destination address." + DECODING + "Note: ether2/ip/ipip4/udp is a different protocolDirID than + ether2/ip/udp, as identified in the protocolDirTable. As such, + two different local protocol index values will be assigned by the + agent. E.g. (full INDEX values shown): + ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0 + ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 " + + + +Bierman & Iddon Standards Track [Page 28] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + 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 + } + +5.3.2. IPX + +ipx PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "Novell IPX" + CHILDREN + "Children of IPX are defined by the 16 bit value of the + Destination Socket field. The value is encoded into an octet + string as [ 0.0.a.b ], where 'a' and 'b' are the network byte + order encodings of the MSB and LSB of the destination socket + field." + ADDRESS-FORMAT + "4 bytes of Network number followed by the 6 bytes Host address + each in network byte order". + REFERENCE + "The IPX protocol is defined by the Novell Corporation + + + + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 29] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + A complete description of IPX may be secured at the following + address: + Novell, Inc. + 122 East 1700 South + P. O. Box 5900 + Provo, Utah 84601 USA + 800 526 5463 + Novell Part # 883-000780-001" + ::= { + ether2 0x8137, -- 0.0.129.55 + llc 0xe0e003, -- 0.224.224.3 + snap 0x8137, -- 0.0.129.55 + ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023) + } + +5.3.3. ARP + +arp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "An Address Resolution Protocol message (request or response). + This protocol does not include Reverse ARP (RARP) packets, which + are counted separately." + REFERENCE + "RFC 826 [RFC826] defines the Address Resolution Protocol." + ::= { + ether2 0x806, -- [ 0.0.8.6 ] + snap 0x806 + } + +5.3.4. IDP + +idp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "Xerox IDP" + CHILDREN + "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." + + + + + +Bierman & Iddon Standards Track [Page 30] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + ADDRESS-FORMAT + "4 bytes of Network number followed by the 6 bytes Host address + each in network byte order". + REFERENCE + "Xerox Corporation, Document XNSS 028112, 1981" + ::= { + ether2 0x600, -- [ 0.0.6.0 ] + snap 0x600 + } + +5.3.5. AppleTalk ARP + +atalkarp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "AppleTalk Address Resolution Protocol." + REFERENCE + "AppleTalk Phase 2 Protocol Specification, document ADPA + #C0144LL/A." + ::= { + ether2 0x80f3, -- [ 0.0.128.243 ] + vsnap(0x080007) 0x80f3 + } + +5.3.6. AppleTalk + +atalk PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0), + addressRecognitionCapable(1) + } + DESCRIPTION + "AppleTalk Protocol." + CHILDREN + "Children of ATALK are defined by the 8 bit value of the DDP type + field. The value is encoded into an octet string as [ 0.0.0.a ], + where 'a' is the value of the DDP type field in network byte + order." + ADDRESS-FORMAT + "2 bytes of Network number followed by 1 byte of node id each in + network byte order". + + + + + + + + +Bierman & Iddon Standards Track [Page 31] + +RFC 2074 RMON Protocol Identifiers January 1997 + + + REFERENCE + "AppleTalk Phase 2 Protocol Specification, document ADPA + #C0144LL/A." + ::= { + ether2 0x809b, -- [ 0.0.128.155 ] + vsnap(0x080007) 0x809b + } + +5.4. L4: Children of L3 Protocols + +5.4.1. ICMP + +icmp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Internet Message Control Protocol." + REFERENCE + "RFC 792 [RFC792] defines the Internet Control Message Protocol." + ::= { ip 1 } + +5.4.2. TCP + +tcp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0) + } + DESCRIPTION + "Transmission Control Protocol." + CHILDREN + "Children of TCP are identified by the 16 bit Destination Port + value as specified in RFC 793. They are encoded as [ 0.0.a.b], + where 'a' is the MSB and 'b' is the LSB of the Destination Port + value. Both bytes are encoded in network byte order. For + example, a protocolDirId-fragment of: + 0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23 + + identifies an encapsulation of the telnet protocol + (ether2.ip.tcp.telnet)" + REFERENCE + "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 } + + + +Bierman & Iddon Standards Track [Page 32] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.4.3. UDP + +udp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0) + } + DESCRIPTION + "User Datagram Protocol." + CHILDREN + "Children of UDP are identified by the 16 bit Destination Port + value as specified in RFC 768. They are encoded as [ 0.0.a.b ], + where 'a' is the MSB and 'b' is the LSB of the Destination Port + value. Both bytes are encoded in network byte order. For + example, a protocolDirId-fragment of: + 0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161 + + identifies an encapsulation of SNMP (ether2.ip.udp.snmp)" + REFERENCE + "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 } + +5.5. L5: Application Layer Protocols + +5.5.1. FTP + +5.5.1.1. FTP-DATA + +ftp-data PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "The File Transfer Protocol Data Port; the FTP Server process + default data-connection port. " + REFERENCE + "RFC 959 [RFC959] defines the File Transfer Protocol. Refer to + section 3.2 of [RFC959] for details on FTP data connections." + ::= { tcp 20 } + + + + + + + + +Bierman & Iddon Standards Track [Page 33] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.1.2. FTP Control + +ftp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "The File Transfer Protocol Control Port; An FTP client initiates + an FTP control connection by sending FTP commands from user port + (U) to this port." + REFERENCE + "RFC 959 [RFC959] defines the File Transfer Protocol." + ::= { tcp 21 } + +5.5.2. Telnet + +telnet PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "The Telnet Protocol; The purpose of the TELNET Protocol is to + provide a fairly general, bi-directional, eight-bit byte oriented + communications facility. Its primary goal is to allow a standard + method of interfacing terminal devices and terminal-oriented + processes to each other. " + REFERENCE + "RFC 854 [RFC854] defines the basic Telnet Protocol." + ::= { tcp 23 } + +5.5.3. SMTP + +smtp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "The Simple Mail Transfer Protocol; SMTP control and data + messages are sent on this port." + REFERENCE + "RFC 821 [RFC821] defines the basic Simple Mail Transfer + Protocol." + ::= { tcp 25 } + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 34] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.4. DNS + +domain PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Domain Name Service Protocol; DNS may be transported by either + UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS + requests restricted to 512 bytes in length may be sent to this + port." + REFERENCE + "RFC 1035 [RFC1035] defines the Bootstrap Protocol." + ::= { udp 53, + tcp 53 } + +5.5.5. BOOTP + +5.5.5.1. Bootstrap Server Protocol + +bootps PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Bootstrap Protocol Server Protocol; BOOTP Clients send requests + (usually broadcast) to the bootps port." + REFERENCE + "RFC 951 [RFC951] defines the Bootstrap Protocol." + ::= { udp 67 } + +5.5.5.2. Bootstrap Client Protocol + +bootpc PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Bootstrap Protocol Client Protocol; BOOTP Server replies are + sent to the BOOTP Client using this destination port." + REFERENCE + "RFC 951 [RFC951] defines the Bootstrap Protocol." + ::= { udp 68 } + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 35] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.6. TFTP + +tftp PROTOCOL-IDENTIFIER + PARAMETERS { + tracksSessions(1) + } + ATTRIBUTES { } + DESCRIPTION + "Trivial File Transfer Protocol; Only the first packet of each + TFTP transaction will be sent to port 69. If the tracksSessions + attribute is set, then packets for each TFTP transaction will be + attributed to tftp, instead of the unregistered port numbers that + will be encoded in subsequent packets." + REFERENCE + "RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC + 1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783] + defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines + TFTP Timeout Interval and Transfer Size Options." + + ::= { udp 69 } + +5.5.7. HTTP + +www-http PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Hypertext Transfer Protocol; " + REFERENCE + "RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol + (HTTP/1.0)." + ::= { tcp 80 } + +5.5.8. POP3 + +pop3 PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Post Office Protocol -- Version 3. Clients establish connections + with POP3 servers by using this destination port number." + REFERENCE + "RFC 1725 [RFC1725] defines Version 3 of the Post Office + Protocol." + ::= { tcp 110 } + + + + + + +Bierman & Iddon Standards Track [Page 36] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.9. SUNRPC + +sunrpc PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { + hasChildren(0) -- port mapper function numbers + } + DESCRIPTION + "SUN Remote Procedure Call Protocol. Port mapper function + requests are sent to this destination port." + CHILDREN + Specific RPC functions are represented as children of the sunrpc + protocol. Each 'RPC function protocol' is identified by its + function number assignment. RPC function number assignments are + defined by different naming authorities, depending of the + function identifier value. + From [RFC1831]: + + Program numbers are given out in groups of hexadecimal 20000000 + (decimal 536870912) according to the following chart: + + 0 - 1fffffff defined by rpc@sun.com + 20000000 - 3fffffff defined by user + 40000000 - 5fffffff transient + 60000000 - 7fffffff reserved + 80000000 - 9fffffff reserved + a0000000 - bfffffff reserved + c0000000 - dfffffff reserved + e0000000 - ffffffff reserved + + Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol + identifier component for 'sunrpc', followed by [ a.b.c.d ], where + a.b.c.d is the 32 bit binary RPC program number encoded in + network byte order. For example, a protocolDirID-fragment value + of: + 0.0.0.111.0.1.134.163 + + defines the NFS function (and protocol). + + Children are named as 'sunrpc' followed by the RPC function + number in base 10 format. For example, NFS would be named: + 'sunrpc 100003'. + REFERENCE + "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 } + + + +Bierman & Iddon Standards Track [Page 37] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.10. NFS + +nfs PROTOCOL-IDENTIFIER + PARAMETERS { + countsFragments(0) + } + ATTRIBUTES { } + DESCRIPTION + "Sun Network File System (NFS);" + DECODING + "The first packet in an NFS transaction is sent to the port- + mapper, and therefore decoded statically by monitoring RFC + portmap requests [RFC1831]. Any subsequent NFS fragments must be + decoded and correctly identified by 'remembering' the port + assignments used in each RPC function call (as identified + according to the procedures in the RPC Specification Version 2 + [RFC1831]). + + The 'countsFragments(0)' PARAMETER bit is used to indicate + whether the probe can (and should) monitor portmapper activity to + correctly attribute all NFS packets." + REFERENCE + "The NFS Version 3 Protocol Specification is defined in RFC 1813 + [RFC1813]." + ::= { + sunrpc 100003 -- [0.1.134.163] + } + +5.5.11. SNMP + +5.5.11.1. SNMP Request/Response + +snmp PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 + protocol versions. Does not include SNMP trap packets." + REFERENCE + "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP + protocol is defined in RFC 1905 [RFC1905]. Transport mappings + are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) + [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." + ::= { + udp 161, + ipx 0x900f, -- [ 0.0.144.15 ] + atalk 8 + } + + + +Bierman & Iddon Standards Track [Page 38] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +5.5.11.2. SNMP Trap + +snmptrap PROTOCOL-IDENTIFIER + PARAMETERS { } + ATTRIBUTES { } + DESCRIPTION + "Simple Network Management Protocol Trap Port." + REFERENCE + "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP + protocol is defined in RFC 1905 [RFC1905]. Transport mappings + are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) + [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." + ::= { + udp 162, + ipx 0x9010, + atalk 9 + } + +6. Acknowledgements + + This document was produced by the IETF RMONMIB Working Group. + + 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. + + + + + + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 39] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +7. References + +[RFC768] + Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + +[RFC791] + Postel, J., ed., "Internet Protocol - DARPA Internet Program + Protocol Specification", STD 5, RFC 791, USC/Information Sciences + Institute, September 1981. + +[RFC792] + Postel, J., "Internet Control Message Protocol - DARPA Internet + Program Protocol Specification", STD 5, RFC 792, USC/Information + Sciences Institute, September 1981. + +[RFC793] + Postel, J., "Transmission Control Protocol - DARPA Internet Program + Protocol Specification", STD 5, RFC 793, USC/Information Sciences + Institute, September 1981. + +[RFC821] + Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + +[RFC826] + Plummer, D., "An Ethernet Address Resolution Protocol or + "Converting Network Protocol Addresses to 48-bit Ethernet Addresses + for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS, + November 1982. + +[RFC854] + Postel, J. and J. Reynolds, "Telnet Protocol Specification", + STD 8, RFC 854, ISI, May 1983. + +[RFC894] + Hornig, C., "A Standard for the Transmission of IP Datagrams over + Ethernet Networks", RFC 894, Symbolics, April 1984. + +[RFC951] + Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951, + Stanford and SUN Microsytems, September 1985. + +[RFC959] + Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8, + RFC 959, USC/Information Sciences Institute, October 1985. + + + + + +Bierman & Iddon Standards Track [Page 40] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +[RFC1035] + Mockapetris, P., "Domain Names - Implementation and Specification", + STD 13, RFC 1035, USC/Information Sciences Institute, November + 1987. + +[RFC1157] + Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network + Management Protocol", STD 15, RFC 1157, SNMP Research, + Performance Systems International, MIT Laboratory for Computer + Science, May 1990. + +[RFC1213] + McCloghrie, K., and M. Rose, Editors, "Management Information Base + for Network Management of TCP/IP-based internets: MIB-II", STD 17, + RFC 1213, Hughes LAN Systems, Performance Systems International, + March 1991. + +[RFC1350] + Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July + 1992. + +[RFC1419] + Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, + Novell, Inc., Apple Computer, Inc., March 1993. + +[RFC1420] + Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993. + +[RFC1700] + Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + USC/Information Sciences Institute, October 1994. + +[RFC1725] + Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC + 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. + +[RFC1757] + S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie + Mellon University, February 1995. + +[RFC1782] + Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782, + Xylogics, Inc., Hewlett Packard Co., March 1995. + +[RFC1783] + Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783, + Xylogics, Inc., Hewlett Packard Co., March 1995. + + + + +Bierman & Iddon Standards Track [Page 41] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +[RFC1784] + Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size + Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March + 1995. + +[RFC1800] + Postel, J., Editor, "Internet Official Protocol Standards", STD 1, + RFC 1920, IAB, March 1996. + +[RFC1831] + Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC + 1831, Sun Microsystems, Inc., August 1995. + +[RFC1902] + SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Structure of Management Information for version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + +[RFC1903] + SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Textual Conventions for version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + +[RFC1904] + SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Conformance Statements for version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + +[RFC1905] + SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Protocol Operations for version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + +[RFC1906] + SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1906, January 1996. + +[RFC1945] + Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol -- + HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995. + +[RMON2] + S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft- + ietf-rmonmib-rmon2-03.txt, International Network Services, January + 1996. + + + + +Bierman & Iddon Standards Track [Page 42] + +RFC 2074 RMON Protocol Identifiers January 1997 + + +8. Security Considerations + + Security issues are not discussed in this memo. + +9. Authors' Addresses + + Andy Bierman + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + Phone: 408-527-3711 + EMail: abierman@cisco.com + + + Robin Iddon + 3Com/AXON + 40/50 Blackfrias Street + Edinburgh, UK + + Phone: +44 131.558.3888 + EMail: robin_iddon@3mail.3com.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bierman & Iddon Standards Track [Page 43] + -- cgit v1.2.3