Remote Network Monitoring MIB Protocol Identifier Reference
RFC 2895
Document | Type |
RFC
- Draft Standard
(August 2000)
Updated by RFC 3395
Obsoletes RFC 2074
|
|
---|---|---|---|
Authors | Andy Bierman , Christopher Bucci , Robin Iddon | ||
Last updated | 2015-10-14 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Bert Wijnen | |
Send notices to | (None) |
RFC 2895
' found in the reference protocol-identifier macro examined instead. Note that if an 'ianaAssigned' protocol is defined that is not a variant of any other documented protocol, then the protocol- identifier macro SHOULD be used instead of the protocol-variant- identifier version of the macro. 3.2.6. Mapping of the PARAMETERS Clause The protocolDirParameters object provides an NMS the ability to turn on and off expensive probe resources. An agent may support a given parameter all the time, not at all, or subject to current resource load. The PARAMETERS clause is a list of bit definitions which can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions may be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conforming agent may choose to implement a subset of zero or more of these PARAMETERS. By convention, the following common bit definitions are used by different protocols. These bit positions MUST NOT be used for other parameters. They MUST be reserved if not used by a given protocol. Bits are encoded in a single octet. Bit 0 is the high order (left- most) bit in the octet, and bit 7 is the low order (right-most) bit in the first octet. Reserved bits and unspecified bits in the octet are set to zero. 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). Bierman, et al. Standards Track [Page 17] RFC 2895 RMON PI Reference August 2000 The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but may be equal to zero (empty). 3.2.6.1. Mapping of the 'countsFragments(0)' BIT This bit indicates whether the probe is correctly attributing all fragmented packets of the specified protocol, even if individual frames carrying this protocol cannot be identified as such. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS. This bit MUST 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 more than one protocolDirParameters octet within a protocolDirTable INDEX, in the event an agent can count fragments at more than one protocol layer. 3.2.6.2. Mapping of the 'tracksSessions(1)' BIT The 'tracksSessions(1)' bit indicates whether frames which are part of remapped sessions (e.g. TFTP download sessions) are correctly counted by the probe. For such a protocol, the probe must usually analyze all packets received on the indicated interface, and maintain some state information, (e.g. the remapped UDP port number for TFTP). The semantics of the 'tracksSessions' parameter are independent of the other protocolDirParameters definitions, so this parameter MAY be combined with any other legal parameter configurations. 3.2.7. Mapping of the ATTRIBUTES Clause The protocolDirType object provides an NMS with an indication of a probe's capabilities for decoding a given protocol, or the general attributes of the particular protocol. The ATTRIBUTES clause is a list of bit definitions which are encoded into the associated instance of ProtocolDirType. The BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object. Bierman, et al. Standards Track [Page 18] RFC 2895 RMON PI Reference August 2000 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.8. Mapping of the DESCRIPTION Clause The DESCRIPTION clause provides a textual description of the protocol identified by this macro. Notice that it SHOULD NOT contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses. The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations. 3.2.9. Mapping of the CHILDREN Clause The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections: - Details on the field(s)/value(s) used to select the child protocol, and how that selection process is performed - Details on how the value(s) are encoded in the protocol identifier octet string - Details on how child protocols are named with respect to their parent protocol label(s) The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause. Bierman, et al. Standards Track [Page 19] RFC 2895 RMON PI Reference August 2000 3.2.10. Mapping of the ADDRESS-FORMAT Clause The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses. This clause MUST be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause. 3.2.11. Mapping of the DECODING Clause The DECODING clause provides a description of the decoding procedure for the specified protocol. It contains useful decoding hints for the implementor, but SHOULD NOT over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required. For 'extensible' protocols ('hasChildren(0)' BIT set) this includes offset and type information for the field(s) used for child selection as well as information on determining the start of the child protocol. For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses. The DECODING clause is optional, and MAY be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol. 3.2.12. Mapping of the REFERENCE Clause If a publicly available reference document exists for this protocol it SHOULD be listed here. Typically this will be a URL if possible; if not then it will be the name and address of the controlling body. The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the amount of information which may currently be obtained from an authoritative document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document. The REFERENCE clause is optional, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols). Bierman, et al. Standards Track [Page 20] RFC 2895 RMON PI Reference August 2000 3.3. Evaluating an Index of the ProtocolDirTable The following evaluation is done after a 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 MUST be evenly divisible by four. The protocolDirParameters length MUST 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 MUST NOT be skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can not exist. The base-layer-identifier also contains a 'special function identifier' which may apply to the rest of the protocol identifier. Wild-carding at the base layer within a protocol encapsulation is the only supported special function at this time. (See section 4.1.1.2 for details.) After the protocol-identifier string (which is the value of protocolDirID) has been parsed, each octet of the protocol-parameters string 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' in the RMON Protocol Identifier Macros document [RFC2896]). It is important to note that these macros are conceptually expanded at implementation time, not at run time. If all the macros are expanded completely by substituting all possible values of each label for each child protocol, a list of all possible protocol-identifiers is produced. So 'ip' would result in 5 distinct protocol-identifiers. Likewise each child of 'ip' would map to at least 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, ip over LLC, etc.). Bierman, et al. Standards Track [Page 21] RFC 2895 RMON PI Reference August 2000 4. Base Layer Protocol Identifier Macros The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings. An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol. Refer to the RMON Protocol Identifier Macros document [RFC2896] for a listing of the non-base layer PI macros published by the working group. Note that other PI macro documents may exist, and it should be possible for an implementor to populate the protocolDirTable without the use of the PI Macro document [RFC2896]. 4.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. 4.1.1. Protocol Identifier Functions The base layer identifier contains information about any special functions to perform during collections of this protocol, as well as the base layer encapsulation identifier. The first three octets of the identifier contain the function code and two optional operands. The fourth octet contains the particular base layer encapsulation used in this protocol (fig. 2). Bierman, et al. Standards Track [Page 22] RFC 2895 RMON PI Reference August 2000 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) 4.1.1.1. Function 0: None If the function ID field (1st octet) is equal to zero, 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. 4.1.1.2. Function 1: Protocol Wildcard Function The wildcard function (function-ID = 1), is used to aggregate counters, by using a single protocol value to indicate potentially many base layer encapsulations of a particular network layer protocol. A protocolDirEntry of this type will match any base-layer encapsulation of the same network layer protocol. The 'op1' field (2nd octet) is not used and MUST be set to zero. The 'op2' field (3rd octet) is not used and MUST be set to zero. Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. The lowest possible base layer value SHOULD be chosen. So, if an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation. If not then an encapsulation over LLC should be used, if permitted. And so on for each of the defined base layers. It should be noted that an agent does not have to support the non- wildcard protocol identifier over the same base layer. For instance a token ring only device would not normally support IP over the ether2 base layer. Nevertheless it should use the ether2 base layer for defining the wildcard IP encapsulation. The agent MAY also support counting some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RFC2021] does not require that agents maintain 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. Bierman, et al. Standards Track [Page 23] RFC 2895 RMON PI Reference August 2000 4.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 value for the ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in the table 4.2 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. Very few new base encapsulations (e.g. for new media types) are expected to be added over time. Table 4.2 Base Layer Encoding Values -------------------------------------- Name ID ------------------ ether2 1 llc 2 snap 3 vsnap 4 ianaAssigned 5 -- Ether2 Encapsulation ether2 PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), 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. Bierman, et al. Standards Track [Page 24] RFC 2895 RMON PI Reference August 2000 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 high order byte and low order byte of the Ethernet-II type value. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. Children of ether2 are named as 'ether2' followed by the type field value in hexadecimal. The above example would be declared as: ether2 0x0800" ADDRESS-FORMAT "Ethernet addresses are 6 octets in network order." DECODING "Only type values greater than 1500 decimal indicate Ethernet-II frames; lower values indicate 802.3 encapsulation (see below)." REFERENCE "The authoritative list of Ether Type values is identified by the URL: ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" ::= { 1 } -- LLC Encapsulation llc PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "The Logical Link Control (LLC) 802.2 protocol." CHILDREN "The LLC Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) 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). Bierman, et al. Standards Track [Page 25] RFC 2895 RMON PI Reference August 2000 Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol identifier component for LLC followed by [ 0.0.0.a ] where 'a' is the SAP value which maps to the child protocol. For example, a protocolDirID-fragment value of: 0.0.0.2.0.0.0.240 defines NetBios over LLC. Children are named as 'llc' followed by the SAP value in hexadecimal. So the above example would have been named: llc 0xf0" ADDRESS-FORMAT "The address consists of 6 octets of MAC address in network order. Source routing bits should be stripped out of the address if present." DECODING "Notice that LLC has a variable length protocol header; there are always three octets (DSAP, SSAP, control). Depending on the value of the control bits in the DSAP, SSAP and control fields there may be an additional octet of control information. LLC can be present on several different media. For 802.3 and 802.5 its presence is mandated (but see ether2 and raw 802.3 encapsulations). For 802.5 there is no other link layer protocol. Notice also that the raw802.3 link layer protocol may take precedence over this one in a protocol specific manner such that it may not be possible to utilize all LSAP values if raw802.3 is also present." REFERENCE "The authoritative list of LLC LSAP values is controlled by the IEEE Registration Authority: IEEE Registration Authority c/o Iris Ringel IEEE Standards Dept 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331 Phone +1 908 562 3813 Fax: +1 908 562 1571" ::= { 2 } -- SNAP over LLC (Organizationally Unique Identifier, OUI=000) -- Encapsulation snap PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { Bierman, et al. Standards Track [Page 26] RFC 2895 RMON PI Reference August 2000 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 Protocol Identifier field (PID) 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 high order byte and low order byte of the Ethernet-II type value. For example, a protocolDirID-fragment value of: 0.0.0.3.0.0.8.0 defines the IP/SNAP protocol. Children of this protocol are named 'snap' followed by the Ethernet-II type value in hexadecimal. The above example would be named: snap 0x0800" ADDRESS-FORMAT "The address format for SNAP is the same as that for LLC" DECODING "SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA and a single control octet will be present. There are then three octets of Organizationally Unique Identifier (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 } Bierman, et al. Standards Track [Page 27] RFC 2895 RMON PI Reference August 2000 -- Vendor SNAP over LLC (OUI != 000) Encapsulation vsnap PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "This pseudo-protocol handles all SNAP packets which do not have a zero OUI. See 'snap' above for details of those that have a zero OUI value." CHILDREN "Children of 'vsnap' are selected by the 3 octet OUI; the PID is not parsed; child protocols are deemed to start with the first octet of the SNAP PID field, and continue to the end of the packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order. For example, a protocolDirID-fragment value of: 0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols over vsnap. Children are named as 'vsnap <OUI>', where the '<OUI>' field is represented as 3 octets in hexadecimal notation. So the above example would be named: 'vsnap 0x080007'" ADDRESS-FORMAT "The LLC address format is inherited by 'vsnap'. See the 'llc' protocol identifier for more details." DECODING "Same as for 'snap' except the OUI is non-zero and the SNAP Protocol Identifier is not parsed." REFERENCE "SNAP Identifier values are assigned by the IEEE Standards Office. The address is: IEEE Registration Authority c/o Iris Ringel IEEE Standards Dept 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331 Phone +1 908 562 3813 Fax: +1 908 562 1571" ::= { 4 } Bierman, et al. Standards Track [Page 28] RFC 2895 RMON PI Reference August 2000 -- IANA Assigned Protocols ianaAssigned PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { } DESCRIPTION "This branch contains protocols which do not conform easily to the hierarchical format utilized in the other link layer branches. Usually, such a protocol 'almost' conforms to a particular 'well-known' identifier format, but additional criteria are used (e.g. configuration-based), making protocol identification difficult or impossible by examination of appropriate network traffic (preventing the any 'well-known' protocol-identifier macro from being used). Sometimes well-known protocols are simply remapped to a different port number by one or more venders (e.g. SNMP). These protocols can be identified with the 'limited extensibility' feature of the protocolDirTable, and do not need special IANA assignments. A centrally located list of these enumerated protocols must be maintained by IANA to insure interoperability. (See section 2.3 for details on the document update procedure.) Support for new link-layers will be added explicitly, and only protocols which cannot possibly be represented in a better way will be considered as 'ianaAssigned' protocols. IANA protocols are identified by the base-layer-selector value [ 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer value corresponding to the particular IANA protocol. Do not create children of this protocol unless you are sure that they cannot be handled by the more conventional link layers above." CHILDREN "Children of this protocol are identified by implementation- specific means, described (as best as possible) in the 'DECODING' clause within the protocol-variant-identifier macro for each enumerated protocol. Children of this protocol are encoded as [ 0.0.0.5 ], the protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ] where 'a', 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol. Bierman, et al. Standards Track [Page 29] RFC 2895 RMON PI Reference August 2000 For example, a protocolDirID-fragment value of: 0.0.0.5.0.0.0.1 defines the IPX protocol encapsulated directly in 802.3 Children are named 'ianaAssigned' followed by the numeric value of the particular IANA assigned protocol. The above example would be named: 'ianaAssigned 1' " DECODING "The 'ianaAssigned' base layer is a pseudo-protocol and is not decoded." REFERENCE "Refer to individual PROTOCOL-IDENTIFIER macros for information on each child of the IANA assigned protocol." ::= { 5 } -- The following protocol-variant-identifier macro declarations are -- used to identify the RMONMIB IANA assigned protocols in a -- proprietary way, by simple enumeration. ipxOverRaw8023 PROTOCOL-IDENTIFIER VARIANT-OF ipx PARAMETERS { } ATTRIBUTES { } DESCRIPTION "This pseudo-protocol describes an encapsulation of IPX over 802.3, without a type field. Refer to the macro for IPX for additional information about this protocol." DECODING "Whenever the 802.3 header indicates LLC a set of protocol specific tests needs to be applied to determine whether this is a 'raw8023' packet or a true 802.2 packet. The nature of these tests depends on the active child protocols for 'raw8023' and is beyond the scope of this document." ::= { ianaAssigned 1, -- [0.0.0.1] 802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1] } Bierman, et al. Standards Track [Page 30] RFC 2895 RMON PI Reference August 2000 4.3. Encapsulation Layers Encapsulation layers are positioned between the base layer and the network layer. It is an implementation-specific matter whether a probe exposes all such encapsulations in its RMON-2 Protocol Directory. 4.3.1. IEEE 802.1Q RMON probes may encounter 'VLAN tagged' frames on monitored links. The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and [IEEE802.1D-1998], define an encapsulation layer inserted after the MAC layer and before the network layer. This section defines a PI macro which supports most (but not all) features of that encapsulation layer. Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header. It is an implementation specific matter whether an RMON probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native (LLC-N) format, for the purpose of RMON collection. In order to support the Ethernet and LLC-N formats in the most efficient manner, and still maintain alignment with the RMON-2 ' collapsed' base layer approach (i.e., support for snap and vsnap), the children of 802dot1Q are encoded a little differently than the children of other base layer identifiers. 802-1Q PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0) } DESCRIPTION "IEEE 802.1Q VLAN Encapsulation header. Note that the specific encoding of the TPID field is not explicitly identified by this PI macro. Ethernet-encoded vs. SNAP-encoded TPID fields can be identified by the ifType of the data source for a particular RMON collection, since the SNAP- encoded format is used exclusively on Token Ring and FDDI media. Also, no information held in the TCI field (including the TR- encap bit) is identified in protocolDirID strings utilizing this PI macro." Bierman, et al. Standards Track [Page 31] RFC 2895 RMON PI Reference August 2000 CHILDREN "The first byte of the 4-byte child identifier is used to distinguish the particular base encoding that follows the 802.1Q header. The remaining three bytes are used exactly as defined by the indicated base layer encoding. In order to simplify the child encoding for the most common cases, the 'ether2' and 'snap' base layers are combined into a single identifier, with a value of zero. The other base layers are encoded with values taken from Table 4.2. 802-1Q Base ID Values --------------------- Base Table 4.2 Base-ID Layer Encoding Encoding ------------------------------------- ether2 1 0 llc 2 2 snap 3 0 vsnap 4 4 ianaAssigned 5 5 The generic child layer-identifier format is shown below: 802-1Q Child Layer-Identifier Format +--------+--------+--------+--------+ | Base | | | ID | base-specific format | | | | +--------+--------+--------+--------+ | 1 | 3 | octet count Base ID == 0 ------------ For payloads encoded with either the Ethernet or LLC/SNAP headers following the VLAN header, children of this protocol are identified exactly as described for the 'ether2' or 'snap' base layers. Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the Ethernet-II type value. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.0.0.8.0 defines IP, VLAN-encapsulated in ether2. Bierman, et al. Standards Track [Page 32] RFC 2895 RMON PI Reference August 2000 Children of this format are named as '802-1Q' followed by the type field value in hexadecimal. So the above example would be declared as: '802-1Q 0x0800'. Base ID == 2 ------------ For payloads encoded with a (non-SNAP) LLC header following the VLAN header, children of this protocol are identified exactly as described for the 'llc' base layer. Children are encoded as [ 0.0.129.0 ], the protocol identifier component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the SAP value which maps to the child protocol. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.2.0.0.240 defines NetBios, VLAN-encapsulated over LLC. Children are named as '802-1Q' followed by the SAP value in hexadecimal, with the leading octet set to the value 2. So the above example would have been named: '802-1Q 0x020000f0' Base ID == 4 ------------ For payloads encoded with LLC/SNAP (non-zero OUI) headers following the VLAN header, children of this protocol are identified exactly as described for the 'vsnap' base layer. Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of protocols, VLAN-encapsulated over vsnap. Children are named as '802-1Q' followed by the <OUI> value, which is represented as 3 octets in hexadecimal notation, with a leading octet set to the value 4. So the above example would be named: '802-1Q 0x04080007'. Bierman, et al. Standards Track [Page 33] RFC 2895 RMON PI Reference August 2000 Base ID == 5 ------------ For payloads which can only be identified as 'ianaAssigned' protocols, children of this protocol are identified exactly as described for the 'ianaAssigned' base layer. Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.5.0.0.0.1 defines the IPX protocol, VLAN-encapsulated directly in 802.3 Children are named '802-1Q' followed by the numeric value of the particular IANA assigned protocol, with a leading octet set to the value of 5. Children are named '802-1Q' followed by the hexadecimal encoding of the child identifier. The above example would be named: '802-1Q 0x05000001'. " DECODING "VLAN headers and tagged frame structure are defined in [IEEE802.1Q]." REFERENCE "The 802.1Q Protocol is defined in the Draft Standard for Virtual Bridged Local Area Networks [IEEE802.1Q]." ::= { ether2 0x8100 -- Ethernet or SNAP encoding of TPID -- snap 0x8100 ** excluded to reduce PD size & complexity } 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to Bierman, et al. Standards Track [Page 34] RFC 2895 RMON PI Reference August 2000 obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document was produced by the IETF RMONMIB Working Group. The authors wish to thank the following people for their contributions to this document: Anil Singhal Frontier Software Development, Inc. Jeanne Haney Bay Networks Dan Hansen Network General Corp. Special thanks are in order to the following people for writing RMON PI macro compilers, and improving the specification of the PI macro language: David Perkins DeskTalk Systems, Inc. Skip Koppenhaver Technically Elite, Inc. 7. References [AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over ATM - Version 1.0", AF- LANE-0021.000, ATM Forum, IBM, January 1995. [AF-NM-TEST-0080.000] Network Management Sub-working Group, Test Sub-working Group, A. Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997. Bierman, et al. Standards Track [Page 35] RFC 2895 RMON PI Reference August 2000 [IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE Computer Society, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specification -- Part 3: Media Access Control (MAC) Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Electrical and Electronics Engineers, Inc., May 1998. [IEEE802.1Q] LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D11, Institute of Electrical and Electronics Engineers, Inc., July 1998. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1902] 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. Bierman, et al. Standards Track [Page 36] RFC 2895 RMON PI Reference August 2000 [RFC1903] 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] 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] 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] 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. [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997. [RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, November 1997. [RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [RFC2272] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. Bierman, et al. Standards Track [Page 37] RFC 2895 RMON PI Reference August 2000 [RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Bierman, et al. Standards Track [Page 38] RFC 2895 RMON PI Reference August 2000 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros", RFC 2896, August 2000. 8. IANA Considerations The protocols identified in this specification are almost entirely defined in external documents. In some rare cases, an arbitrary Protocol Identifier assignment must be made in order to support a particular protocol in the RMON-2 protocolDirTable. Protocol Identifier macros for such protocols will be defined under the ' ianaAssigned' base layer (see sections 3. and 4.2). At this time, only one protocol is defined under the ianaAssigned base layer, called 'ipxOverRaw8023' (see section 4.2). 9. Security Considerations This document discusses the syntax and semantics of textual descriptions of networking protocols, not the definition of any networking behavior. As such, no security considerations are raised by this memo. Bierman, et al. Standards Track [Page 39] RFC 2895 RMON PI Reference August 2000 10. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 EMail: abierman@cisco.com Chris Bucci Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-5337 EMail: cbucci@cisco.com Robin Iddon c/o 3Com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh, EH1 1NE, UK Phone: +44 131.558.3888 EMail: None Bierman, et al. Standards Track [Page 40] RFC 2895 RMON PI Reference August 2000 Appendix A: Changes since RFC 2074 The differences between RFC 2074 and this document are: - RFC 2074 has been split into a reference document (this document) on the standards track and an informational document [RFC2896], in order to remove most protocol identifier macros out of the standards track document. - Administrative updates; added an author, added copyrights, updated SNMP framework boilerplate; - Updated overview section. - Section 2.1 MUST, SHOULD text added per template - Section 2.1 added some new terms - parent protocol - child protocol - protocol encapsulation tree - Added section 2.3 about splitting into 2 documents: "Relationship to the RMON Protocol Identifier Macros Document" - Added section 2.4 "Relationship to the ATM-RMON MIB" - rewrote section 3.2 "Protocol Identifier Macro Format" But no semantic changes were made; The PI macro syntax is now specified in greater detail using BNF notation. - Section 3.2.3.1 "Mapping of the 'countsFragments(0)' BIT" - this section was clarified to allow multiple protocolDirParameters octets in a given PI string to set the 'countsFragments' bit. The RFC version says just one octet can set this BIT. It is a useful feature to identify fragmentation at multiple layers, and most RMON-2 agents were already doing this, so the WG agreed to this clarification. - Added section 4.3 "Encapsualtion Layers" - This document ends after the base layer encapsulation definitions (through RFC 2074, section 5.2) - Added Intellectual Property section - Moved RFC 2074 section 5.3 "L3: Children of Base Protocol Identifiers" through the end of RFC 2074, to the PI Reference [RFC2896] document, in which many new protocol identifier macros were added for application protocols and non-IP protocol stacks. - Acknowledgements section has been updated Bierman, et al. Standards Track [Page 41] RFC 2895 RMON PI Reference August 2000 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman, et al. Standards Track [Page 42]