idnits 2.17.1 draft-ietf-rmonmib-rmonprot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 394 has weird spacing: '...agments high...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 1995) is 10382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 1413, but not defined ** Obsolete normative reference: RFC 1442 (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 ** Obsolete normative reference: RFC 1448 (Obsoleted by RFC 1905) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1757 (Obsoleted by RFC 2819) ** Obsolete normative reference: RFC 1800 (Obsoleted by RFC 1880) -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RMON2' Summary: 17 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft RMON Protocol Identifiers November 17, 1995 3 Remote Network Monitoring MIB Protocol Identifiers 4 6 17 November 1995 8 Andy Bierman 9 Bierman Consulting 10 abierman@west.net 12 Robin Iddon 13 AXON Networks, Inc. 14 robini@axon.com 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 Draft RMON Protocol Identifiers November 17, 1995 35 1. Introduction 37 This memo defines an experimental portion of the Management Information 38 Base (MIB) for use with network management protocols in the Internet 39 community. In particular, it describes the algorithms required to 40 identify different protocol encapsulations managed with the Remote 41 Network Monitoring MIB Version 2 (RMON-2) [RMON2]. Although related to 42 the original Remote Network Monitoring MIB (RMON) [RFC1757], this 43 document refers only to objects found in the RMON-2 MIB. 45 1.1. The SNMPv2 Network Management Framework 47 The SNMPv2 Network Management Framework consists of four major 48 components. They are: 50 o RFC 1442 [RFC1442] which defines the SMI, the mechanisms used for 51 describing and naming objects for the purpose of management. 53 o STD 17, RFC 1213 [RFC1213] defines MIB-II, the core set of managed 54 objects for the Internet suite of protocols. 56 o RFC 1445 [RFC1445] which defines the administrative and other 57 architectural aspects of the framework. 59 o RFC 1448 [RFC1448] which defines the protocol used for network 60 access to managed objects. 62 The Framework permits new objects to be defined for the purpose of 63 experimentation and evaluation. 65 1.1.1. Object Definitions 67 Managed objects are accessed via a virtual information store, termed the 68 Management Information Base or MIB. Objects in the MIB are defined 69 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 70 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 71 an administratively assigned name. The object type together with an 72 object instance serves to uniquely identify a specific instantiation of 73 the object. For human convenience, we often use a textual string, 74 termed the descriptor, to refer to the object type. 76 Draft RMON Protocol Identifiers November 17, 1995 78 2. Overview 80 The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to 81 globally identify specific protocol encapsulations in the 82 protocolDirTable. 84 This guide contains algorithms and examples of protocol identifier 85 encapsulations for use as INDEX values in the protocolDirTable. 87 This document is not intended to be an authoritative reference on the 88 protocols described herein. Refer to the Official Internet Standards 89 document (RFC 1800) [RFC1800], the Assigned Numbers document (RFC 1700) 90 [RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete 91 and authoritative protocol information. 93 2.1. Terms 95 Several terms are used throughout this document, as well as in the 96 RMON-2 MIB [RMON2], that should be introduced: 98 layer-identifier: 99 An octet string fragment representing a particular protocol 100 encapsulation layer. A layer-identifier is composed of one or more 101 layer-identifier-components. An implementation must recognize the 102 number of layer-identifier-components in a non-standard way, since 103 there is no layer-identifier-component-count octet encoded into a 104 protocol-identifier string. 106 layer-identifier-component: 107 A four-octet string fragment identifying some or all of a 108 particular protocol encapsulation layer. This string is always 109 exactly four octets in length and encoded in network byte order. A 110 particular protocol encapsulation can be identified by starting 111 with a MAC layer encapsulation (see the 'L2 Protocol Identifiers' 112 section for more detail), and following the encoding rules 113 specified in the CHILDREN clause and assignment section for that 114 layer. Then repeat for each identified layer in the encapsulation. 115 (See the section 'Evaluating a Protocol-Identifier INDEX' for more 116 detail.) 118 protocol: 119 A particular protocol layer, as specified by encoding rules in this 120 document. Usually refers to a single layer in a given 121 encapsulation. Note that this term is sometimes used in the RMON-2 123 Draft RMON Protocol Identifiers November 17, 1995 125 MIB [RMON2] to name a fully-specified protocol-identifier string. 126 In such a case, the protocol-identifier string is named for its 127 upper-most layer. A named protocol may also refer to any 128 encapsulation of that protocol. 130 protocol-identifier string: 131 An octet string representing a particular protocol encapsulation, 132 as specified by encoding rules in this document. This string is 133 identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A 134 protocol protocol-identifier string is composed of one or more 135 layer-identifiers. 137 protocol-identifier macro: 138 A group of formatted text describing a particular protocol layer, 139 as used within the RMON-2 MIB [RMON2]. The macro serves several 140 purposes: 142 - Name the protocol for use within the RMON-2 MIB [RMON2]. 143 - Describe how the protocol is encoded into an octet string. 144 - Describe how child protocols are identified (if applicable), 145 and encoded into an octet string. 146 - Describe which protocolDirParameters are allowed for the protocol. 147 - Describe how the associated protocolDirType object is encoded 148 for the protocol. 149 - Provide reference(s) to authoritative documentation for the 150 protocol. 152 protocol-parameter: 153 A single octet, corresponding to a specific layer-identifier- 154 component in the protocol-identifier. This octet is a bit-mask 155 indicating special functions or capabilities that this agent is 156 providing for the corresponding protocol. 158 protocol-parameters string: 159 An octet string, which contains one protocol-parameter for each 160 layer-identifier-component in the protocol-identifier. See the 161 section 'Mapping of the PARAMETERS Clause' for more detail. This 162 string is identified in the RMON-2 MIB [RMON2] as the 163 protocolDirParameters object. 165 protocolDirTable INDEX: 166 A protocol-identifier and protocol-parameters octet string pair 167 that have been converted to an INDEX value, according to the 168 encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212]. 170 Draft RMON Protocol Identifiers November 17, 1995 172 pseudo-protocol: 173 A convention or algorithm used only within this document for the 174 purpose of encoding protocol-identifier strings. 176 2.2. Relationship to the Remote Network Monitoring MIB 178 This document is intended to identify possible string values for the 179 OCTET STRING objects protocolDirID and protocolDirParameters. Tables in 180 the new Protocol Distribution, Host, and Matrix groups use a local 181 INTEGER INDEX, in order to remain unaffected by changes in this 182 document. Only the protocolDirTable uses the strings (protocolDirID and 183 protocolDirParameters) described in this document. 185 This document is not intended to limit the protocols that may be 186 identified for counting in the RMON-2 MIB. Many protocol encapsulations, 187 not explicitly identified in this document, may be present in an actual 188 implementation of the protocolDirTable. Also, implementations of the 189 protocolDirTable may not include all the protocols identified in the 190 example section below. 192 2.3. Relationship to the Other MIBs 194 The RMON Protocol Identifiers document is intended for use with the 195 protocolDirTable within the RMON MIB. It is not relevant to any other 196 MIB, or intended for use with any other MIB. 198 Draft RMON Protocol Identifiers November 17, 1995 200 3. Protocol Identifier Encoding 202 The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and 203 protocolDirParameters. To encode the table index, each variable-length 204 string is converted to an OBJECT IDENTIFIER fragment, according to the 205 encoding rules in section 4.1.6 of STD 16 (RFC 1212) [RFC1212]. Then the 206 index fragments are simply concatenated. (Refer to figures 1a - 1d below 207 for more detail.) 209 The first OCTET STRING (protocolDirID) is composed of one or more 4- 210 octet "layer-identifiers". The entire string uniquely identifies a 211 particular protocol encapsulation tree. The second OCTET STRING, 212 (protocolDirParameters) which contains a corresponding number of 1-octet 213 protocol-specific parameters, one for each 4-octet layer-identifier in 214 the first string. 216 A protocol layer is identified by one or more 32-bit values. Each 217 layer-identifier-value is encoded in the ProtocolDirID OCTET STRING 218 INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each 219 byte of the 32-bit value in network byte order. 221 Notice that each encapsulating layer may use one or more of these layer 222 identifiers to indicate the encapsulated protocol. However, there are no 223 actual cases included in this document where this was required. An 224 implementation must determine how many layer-identifiers 225 Draft RMON Protocol Identifiers November 17, 1995 227 The following figures show the differences between the OBJECT IDENTIFIER 228 and OCTET STRING encoding of the protocol identifier string. 230 Fig. 1a 231 protocolDirTable INDEX Format 232 ----------------------------- 234 +---+--------------------------+---+---------------+ 235 | c ! | c ! protocolDir | 236 | n ! protocolDirID | n ! Parameters | 237 | t ! | t ! | 238 +---+--------------------------+---+---------------+ 240 Fig. 1b 241 protocolDirTable OCTET STRING Format 242 ------------------------------------ 244 protocolDirID 245 +----------------------------------------+ 246 | | 247 | 4 * N octets | 248 | | 249 +----------------------------------------+ 251 protocolDirParameters 252 +----------+ 253 | | 254 | N octets | 255 | | 256 +----------+ 258 Fig. 1c 259 protocolDirTable INDEX Format Detail 260 ------------------------------------ 262 protocolDirID protocolDirParameters 263 +---+--------+--------+--------+--------+---+---+---+---+---+ 264 | c | proto | proto | proto | proto | c |par|par|par|par| 265 | n | L2 | L3 | L4 | L5 | n | L2| L3| L4| L5| 266 | t | | | | | t | | | | | 267 +---+--------+--------+--------+--------+---+---+---+---+---+ subOID 268 | 1 | 4 * N2 | 4 * N3 | 4 * N4 | 4 * N5 | 1 | N2| N3| N4| N5| count 270 where Ni is the number of protocol-layer-values required 271 for protocol layer 'i', and 'subOID' is a single 273 Draft RMON Protocol Identifiers November 17, 1995 275 OBJECT IDENTIFIER sub-identifier. 277 Fig. 1d 278 protocolDirTable OCTET STRING Format Detail 279 ------------------------------------------- 281 protocolDirID 282 +--------+--------+--------+--------+ 283 | proto | proto | proto | proto | 284 | L2 | L3 | L4 | L5 | 285 | | | | | 286 +--------+--------+--------+--------+ octet 287 | 4 * N2 | 4 * N3 | 4 * N4 | 4 * N5 | count 289 protocolDirParameters 290 +---+---+---+---+ 291 |par|par|par|par| 292 | L2| L3| L4| L5| 293 | | | | | 294 +---+---+---+---+ octet 295 | N2| N3| N4| N5| count 297 where Ni is the number of protocol-layer-values required 298 for protocol layer 'i'. Note that these two strings would not be 299 concatenated together if ever returned in a GetResponse PDU, 300 since they are different MIB objects. (However, protocolDirID and 301 protocolDirParameters are not currently readable MIB objects.) 303 Although this example indicates four encapsulated protocols, in 304 practice, any non-zero number of layer-identifiers may be present, 305 theoretically limited only by OBJECT IDENTIFIER length restrictions, as 306 specified in section 7.1.3 of RFC 1442 [RFC1442]. 308 3.1. ProtocolDirTable INDEX Format Examples 310 -- HTTP; fragments counted from IP and above 311 ether2.ip.tcp.www-http = 312 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0 314 -- SNMP over UDP/IP over SNAP 315 snap.ip.udp.snmp = 316 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 318 Draft RMON Protocol Identifiers November 17, 1995 320 -- SNMP over IPX over SNAP 321 snap.ipx.snmp = 322 12.0.0.0.3.0.0.129.55.0.0.0.161.3.0.0.0 324 -- SNMP over IPX over raw8023 325 raw8023.ipx.snmp = 326 12.0.0.0.5.0.0.129.55.0.0.0.161.3.0.0.0 328 -- IPX over LLC 329 llc.ipx = 330 8.0.0.0.2.0.224.224.3.2.0.0 332 -- SNMP over UDP/IP over any link layer 333 -- wildcard-ether2.ip.udp.snmp 334 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 336 -- LLC 'others' pseudo-protocol 337 4.0.0.0.2.1.2 339 -- IP over any link layer 'others' pseudo-protocol 340 -- wildcard-ether2.ip(others) 341 8.1.0.0.1.0.0.8.0.2.0.2 343 3.2. Protocol Identifier Macro Format 345 The following example is meant to introduce the PROTOCOL-IDENTIFIER 346 macro syntax. The syntax is not ASN.1; The definitive BNF definitions 347 for the protocol-identifier macro syntax can be found in Appendix A. 349 protocol-identifier :== 350 "PROTOCOL-IDENTIFIER" 351 "PARAMETERS" "{" "}" 352 "ATTRIBUTES" "{" "}" 353 "DESCRIPTION" """ """ 354 [ "CHILDREN" """ """ ] 355 [ "ADDRESS-FORMAT" """ """ ] 356 [ "DECODING" """ """ ] 357 [ "REFERENCE" """ """ ] 358 "::=" "{" "}" 360 3.2.1. Mapping of the Protocol Name 362 The 'protocol-name' value must be an lower-case ASCII string, and if 363 possible, should match the "most well-known" name or acronym for the 364 Draft RMON Protocol Identifiers November 17, 1995 366 indicated protocol. For example, the document indicated by the URL: 368 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 370 defines IP Protocol field values, so protocol-identifier macros for 371 children of IP should be given names consistent with the protocol names 372 found in this authoritative document. 374 3.2.2. Mapping of the PARAMETERS Clause 376 The PARAMETERS clause is a list of bit definitions which can be directly 377 encoded into the associated ProtocolDirParameters octet in network byte 378 order. Zero or more bit definitions may be present. Only bits 0-7 are 379 valid encoding values. This clause defines the entire BIT set allowed 380 for a given protocol. A conformant agent may choose to implement a 381 subset of zero or more of these PARAMETERS. 383 By convention, the following common bit definitions are used by 384 different protocols. These bit positions must not be used for other 385 parameters. They should be reserved if not used by a given protocol. 387 Draft RMON Protocol Identifiers November 17, 1995 389 Table 3.1 Reserved PARAMETERS Bits 390 ------------------------------------ 392 Bit Name Description 393 --------------------------------------------------------------------- 394 0 countsFragments higher-layer protocols encapsulated within 395 this protocol will be counted correctly even 396 if this protocol fragments the upper layers 397 into multiple packets. 398 1 others this parameter is used to identify a 'pseudo- 399 protocol' -- the children of the protocol 400 encapsulation identified by the protocolDirID 401 portion of the INDEX, which are not otherwise 402 identified by entries in the protocolDirTable. 403 This is a valid parameter for all extensible 404 protocols. 405 2 trackSessions correctly attributes all packets of a protocol 406 which starts sessions on well known ports or 407 sockets and then transfers them to dynamically 408 assigned ports or sockets thereafter (e.g. TFTP). 410 The PARAMETERS clause must be present in all protocol-identifier macro 411 declarations, but may be empty. 413 3.2.2.1. Mapping of the 'countsFragments(0)' BIT 415 This bit indicates whether the probe is correctly attributing all 416 fragmented packets of the specified protocol, even if individual frames 417 carrying this protocol cannot be identified as such. Note that the 418 probe is not required to actually present any re-assembled datagrams 419 (for address-analysis, filtering, or any other purpose) to the NMS. 421 This bit may only be set in a protocolDirParameters octet which 422 corresponds to a protocol that supports fragmentation and reassembly in 423 some form. Note that TCP packets are not considered 'fragmented-streams' 424 and so TCP is not eligible. 426 This bit may be set in at most one protocolDirParameter octet within a 427 protocolDirTable INDEX. 429 Draft RMON Protocol Identifiers November 17, 1995 431 3.2.2.2. Mapping of the 'others(1)' BIT 433 The 'others(1)' BIT is handled in a special way. The unique OCTET 434 STRING created with the others(1) bit set in the last 435 protocolDirParameters octet identifies the 'others' pseudo-protocol. 436 Note that corresponding protocolDirEntry, (i.e. identical, but without 437 the 'others' bit set), may or may not be present in the 438 protocolDirTable. 440 Only the un-attributed protocols ('others') counters are kept for this 441 pseudo-protocol. If the unknown protocol occurs above the network layer, 442 then host and matrix entries can be maintained for the 'others' entry, 443 otherwise only a protocol distribution entry can be kept. Only the last 444 protocol specified in the protocolDirID can set the 'others' bit in the 445 corresponding protocolDirParameters octet. 447 For example, to indicate all unknown ETHER TYPES, the protocol 448 identifier '4.0.0.0.1.1.2' would be used. An agent might assign this 449 protocol a local index value of '42'. After creating the appropriate 450 control entry, protocolDistStatsPkts.1.42 would contain the unknown 451 ETHER TYPES packet count, and protocolDistStatsOctets.1.42 would contain 452 the unknown ETHER TYPES octet count. 454 The following examples show identifiers for 'ip(others)' and 455 'tcp(others)' 457 ether2.ip(others) = 8.0.0.0.1.0.0.8.0.0.2.0.2 459 ether2.ip.tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.0.2 461 -- the following identifier is illegal 462 ether2.ip(others).tcp(others) = 12.0.0.0.1.0.0.8.0.0.0.0.6.3.0.2.2 464 3.2.2.2.1. Relationship to the protocolDirTable 466 The protocol-collection control objects (e.g. protocolDirHostConfig) can 467 affect the overall consistency of counter values retrieved by a 468 management station, since collection of given protocols can be enabled 469 or disabled while collection is running. Also, protocols may be added to 470 the protocolDirTable while collections are in progress. 472 The following 'counting' rules must be implemented by a probe to ensure 473 that consistent data is returned to the management station: 475 Draft RMON Protocol Identifiers November 17, 1995 477 - If collection of a child protocol is disabled in a given table with 478 one of the protocolDir*Config objects, then the counts for this 479 protocol are 'conceptually' added to the 'parent-protocol' counter, 480 if that protocol is being counted. This action must be transparent 481 to the management station, since counters for the parent-protocol 482 cannot be affected by configuration switches for upper-layer 483 protocols. 485 - If collection of a child protocol is enabled at some time after 486 collection of 'others' counts for the parent has begun, (either 487 because some instance of protocolDir*Config was changed or a new 488 protocolDirEntry was created), then the probe must ensure that all 489 counter values are consistent after the child protocol collection 490 begins. An RMON-2 probe is required to instantiate counters with a 491 value of zero, which should be enough to meet this requirement. 493 3.2.2.3. Mapping of the 'tracksSessions(2)' BIT 495 The 'tracksSessions(2)' bit indicates whether frames which are part of 496 remapped-sessions (e.g. TFTP download sessions) are correctly counted by 497 the probe. For such a protocol, the probe must usually analyze all 498 packets received on the indicated interface, and maintain some state 499 information, (e.g. the remapped UDP port number for TFTP). 501 The semantics of the 'trackSessions' parameter are independent of the 502 other protocolDirParameter definitions, so this parameter may be 503 combined with any other legal parameter configurations. 505 3.2.3. Mapping of the ATTRIBUTES Clause 507 The ATTRIBUTES clause is a list of bit definitions which are directly 508 encoded into the associated instance of ProtocolDirType. The BIT 509 definitions are specified in the SYNTAX clause of the protocolDirType 510 MIB object. 512 Draft RMON Protocol Identifiers November 17, 1995 514 Table 3.2 Reserved ATTRIBUTES Bits 515 ------------------------------------ 517 Bit Name Description 518 --------------------------------------------------------------------- 519 0 hasChildren indicates that there may be children of 520 this protocol defined in the protocolDirTable 521 (by either the agent or the manager). 522 1 addressRecognitionCapable 523 indicates that this protocol can be used 524 to generate host and matrix table entries. 526 The ATTRIBUTES clause must be present in all protocol-identifier macro 527 declarations, but may be empty. 529 3.2.4. Mapping of the DESCRIPTION Clause 531 The DESCRIPTION clause provides a textual description of the protocol 532 identified by this macro. Notice that it should not contain details 533 about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and 534 REFERENCE clauses. 536 The DESCRIPTION clause must be present in all protocol-identifier macro 537 declarations. 539 3.2.5. Mapping of the CHILDREN Clause 541 The CHILDREN clause provides a description of child protocols for 542 protocols which support them. It has three sub-sections: 544 - Details on the field(s)/value(s) used to select the child protocol, 545 and how that selection process is performed 547 - Details on how the value(s) are encoded in the protocol identifier 548 octet string 550 - Details on how child protocols are named with respect to their 551 parent protocol label(s) 553 The CHILDREN clause must be present in all protocol-identifier macro 554 declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES 555 clause. 557 Draft RMON Protocol Identifiers November 17, 1995 559 3.2.6. Mapping of the ADDRESS-FORMAT Clause 561 The ADDRESS-FORMAT clause provides a description of the OCTET-STRING 562 format(s) used when encoding addresses. 564 This clause must be present in all protocol-identifier macro 565 declarations in which the 'addressRecognitionCapable(1)' BIT is set in 566 the ATTRIBUTES clause. 568 3.2.7. Mapping of the DECODING Clause 570 The DECODING clause provides a description of the decoding procedure for 571 the specified protocol. It contains useful decoding hints for the 572 implementor, but should not over-replicate information in documents 573 cited in the REFERENCE clause. It might contain a complete description 574 of any decoding information required. 576 For 'extensible' protocols ('hasChildren BIT set) this includes offset 577 and type information for the field(s) used for child selection as well 578 as information on determining the start of the child protocol. 580 For 'addressRecognitionCapable' protocols this includes offset and type 581 information for the field(s) used to generate addresses. 583 The DECODING clause is optional, and may be omitted if the REFERENCE 584 clause contains pointers to decoding information for the specified 585 protocol. 587 3.2.8. Mapping of the REFERENCE Clause 589 If a publicly available reference document exists for this protocol it 590 should be listed here. Typically this will be a URL if possible; if not 591 then it will be the name & address of the controlling body. 593 The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the 594 amount of information which may already be obtained from an 595 'authoritative' document, such as the Assigned Numbers document (RFC 596 1700) [RFC1700]. Any duplication or paraphrasing of information should 597 be brief and consistent with the authoritative document. 599 The REFERENCE clause is optional, but should be implemented if an 600 authoritative reference exists for the protocol (especially for standard 601 protocols). 603 Draft RMON Protocol Identifiers November 17, 1995 605 3.2.9. Evaluating a Protocol-Identifier INDEX 607 The following evaluation is done after protocolDirTable INDEX value has 608 been converted into two OCTET STRINGs according to the INDEX encoding 609 rules specified in RFC 1212. 611 Protocol-identifiers are evaluated left-to-right, starting with the 612 protocolDirID, which length should be evenly divisible by four. The 613 protocolDirParameters length should be exactly one quarter of the 614 protocolDirID string length. 616 Protocol-identifier parsing starts with the MAC layer identifier, which 617 must be present, and continues for one or more upper layer identifiers, 618 until all OCTETs of the protocolDirID have been used. Layers may not be 619 skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can 620 not exist. Wild-carding is only supported at the MAC layer (see the 'L2 621 Protocol Identifiers' section for MAC-wildcard details). 623 After the protocol-tree identified in protocolDirID has been parsed, 624 each parameter bit-mask (one octet for each 4-octet layer-identifier- 625 component) is evaluated, and applied to the corresponding protocol 626 layer. Note that the 'others(1)' BIT may only be set once in a 627 protocolDirParameters string, and that this has to occur in the last 628 octet of the string. This bit is only applicable for protocols in which 629 the 'hasChildren' ATTRIBUTE bit is set. An agent should reject 630 SetRequests in which the 'others(1)' bit in protocolDirParameters is set 631 in any other manner. 633 A protocol-identifier label may map to more than one value. For 634 instance, 'ip' maps to 5 distinct values, one for each supported 635 encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'), 637 It is important to note that these macros are conceptually expanded at 638 implementation time, not at run time. 640 If all the macros are expanded completely by substituting all possible 641 values of each label for each child protocol a list of all possible 642 protocol-identifiers is produced. So 'ip' would result in 5 distinct 643 protocol-identifiers. Likewise each child of 'ip' would map to at least 644 5 protocol-identifiers, one for each encapsulation. 646 Draft RMON Protocol Identifiers November 17, 1995 648 4. Protocol Identifier Macro Examples 650 The following PROTOCOL IDENTIFIER macros can be used to construct 651 protocolDirID and protocolDirParmaters strings. 653 This section is intended to grow over time. Minimal protocol support is 654 included at this time. 656 4.1. L2 Protocol Identifiers 658 The first layer (L2) is mandatory, and defines the MAC encapsulation of 659 the packet. The MAC layer encapsulation is encoded in an octet string as 660 a 4-octet layer identifier, of the form: 662 w.0.a.b 664 where 'w' is the 'anylink' wildcard indicator, and 'a' and 'b' are the 665 network byte order encodings of the MSB and LSB of the "ID" field in 666 table below. 668 The wildcard indicator (0==no wildcard, 1==wildcard), is used to flag 669 the special pseudo-MAC-layer for the purpose of aggregating counts. 671 If the wildcard flag is set in an protocol identifier, then the 672 encapsulation given in 'a.b', (called the 'base encapsulation') is used 673 simply to identify the rest of the protocol layers. This base 674 encapsulation should be the 'ether2' encapsulation, if possible. 676 Note that only one net-layer-encapsulation is actually encoded into the 677 protocol identifier. An agent will need to identify other encapsulations 678 of the indicated network-layer protocol in an implementation-specific 679 manner, and count all matching encapsulations which are part of this 680 'wildcard' protocol. 682 The agent may also be requested to count some or all of the individual 683 encapsulations for the same protocols, in addition to wildcard counting. 685 There is one value for protocolDirParameters defined for the MAC layer 686 at this time; the 'others' counter can be supported at this layer. 688 The suggested ProtocolDirDescr field for the MAC layer is given by the 689 corresponding "Name" field in the table 4.1 below. However, 690 implementations may choose different values. 692 Draft RMON Protocol Identifiers November 17, 1995 694 The MAC layer protocolDirType field should contain bits set for the 695 "hasChildren(0)" and "addressRecognitionCapable(1)" attributes. 697 Table 4.1 MAC Layer Encoding Values 698 ------------------------------------- 700 Name ID 701 ------------------ 702 ether2 1 703 llc 2 704 snap 3 705 vsnap 4 706 raw8023 5 708 4.1.1. Ether2 Encapsulation 710 ether2 PROTOCOL-IDENTIFIER 711 PARAMETERS { 712 others(1) -- The count of ether2 packets that didn't match 713 -- any children of ether2 enabled in the protocolDirectory 714 } 715 ATTRIBUTES { 716 hasChildren(0), 717 addressRecognitionCapable(1) 718 } 719 DESCRIPTION 720 "DIX Ethernet, also called Ethernet-II." 721 CHILDREN 722 "The Ethernet-II type field is used to select child protocols. 723 This is a 16-bit field. Child protocols are deemed to start at 724 the first octet after this type field. 726 Children of this protocol are encoded as [ 0.0.0.1 ], the 727 protocol identifier for 'ether2' followed by [ 0.0.a.b ] where 728 'a' and 'b' are the network byte order encodings of the MSB and 729 LSB of the Ethernet-II type value. 731 For example, a protocolDirID value of: 733 8.0.0.0.1.0.0.8.0 735 defines IP encapsulated in ether2. 737 Children of are named as 'ether2' followed by the type field 739 Draft RMON Protocol Identifiers November 17, 1995 741 value in hexadecimal. The above example would be declared as: 743 ether2 0x0800" 744 ADDRESS-FORMAT 745 "Ethernet addresses are 6 octets in network order." 746 DECODING 747 "Only type values greater than or equal to 1500 decimal indicate 748 Ethernet-II frames; lower values indicate 802.3 encapsulation 749 (see below)." 750 REFERENCE 751 "RFC 894; 752 The authoritative list of Ether Type values is identified 753 by the URL: 755 ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" 756 ::= { 1 } 758 4.1.2. LLC Encapsulation 760 llc PROTOCOL-IDENTIFIER 761 PARAMETERS { 762 others(1) -- The count of llc packets that didn't match 763 -- any children of llc enabled in the protocolDirectory 764 } 765 ATTRIBUTES { 766 hasChildren(0), 767 addressRecognitionCapable(1) 768 } 769 DESCRIPTION 770 "The LLC (802.2) protocol." 771 CHILDREN 772 "The LLC SSAP and DSAP (Source/Dest Service Access Points) are 773 used to select child protocols. Each of these is one octet long, 774 although the least significant bit is a control bit and should be 775 masked out. Typically SSAP and DSAP (once masked) are the same 776 for a given protocol - each end implicitly knows whether it is 777 the server or client in a client/server protocol. This is only a 778 convention, however, and it is possible for them to be different. 779 The SSAP is matched against child protocols first. If none is 780 found then the DSAP is matched instead. The child protocol is 781 deemed to start at the first octet after the LLC control 782 field(s). 784 Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol 785 identifier for LLC followed by [ 0.0.0.a ] where 'a' is the SAP 787 Draft RMON Protocol Identifiers November 17, 1995 789 value which maps to the child protocol. For example, a 790 protocolDirID value of: 792 8.0.0.0.2.0.0.0.240 794 defines NetBios over LLC. 796 Children are named as 'llc' followed by the SAP value in 797 hexadecimal. So the above example would have been named: 799 llc 0xf0" 800 ADDRESS-FORMAT 801 "The address consists of 6 octets of MAC address in network 802 order. Source routing bits should be stripped out of the address 803 if present." 804 DECODING 805 "Notice that LLC has a variable length protocol header; there are 806 always three octets (DSAP, SSAP, control). Depending on the 807 value of the control bits in the DSAP, SSAP and control fields 808 there may be an additional octet of control information. 810 LLC can be present on several different media. For 802.3 and 811 802.5 its presence is mandated (but see ether2 and raw802.3 812 encapsulations). For 802.5 there is no other link layer 813 protocol. 815 Notice also that the raw802.3 link layer protocol may take 816 precedence over this one in a protocol specific manner such that 817 it may not be possible to utilize all LSAP values if raw802.3 is 818 also present." 819 REFERENCE 820 "IEEE 802.2 - [TBD] 822 The authoritative list of LLC LSAP values is controlled by the IEEE 823 Registration Authority: 825 IEEE Registration Authority 826 c/o Iris Ringel 827 IEEE Standards Dept 828 445 Hoes Lane, P.O. Box 1331 829 Piscataway, NJ 08855-1331 830 Phone +1 908 562 3813 831 Fax: +1 908 562 1571" 832 ::= { 2 } 834 Draft RMON Protocol Identifiers November 17, 1995 836 4.1.3. SNAP over LLC (OUI=000) Encapsulation 838 snap PROTOCOL-IDENTIFIER 839 PARAMETERS { 840 others(1) -- The count of snap packets that didn't match 841 -- any children of snap enabled in the protocolDirectory 842 } 843 ATTRIBUTES { 844 hasChildren(0), 845 addressRecognitionCapable(1) 846 } 847 DESCRIPTION 848 "The Sub-Network Access Protocol (SNAP) is layered on top of LLC 849 protocol, allowing Ethernet-II protocols to be run over a media 850 restricted to LLC." 851 CHILDREN 852 "Children of 'snap' are identified by Ethernet-II type values; 853 the SNAP PID (Protocol Identifier) field is used to select the 854 appropriate child. The entire SNAP protocol header is consumed; 855 the child protocol is assumed to start at the next octet after 856 the PID. 858 Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol 859 identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' 860 are the MSB and LSB of the Ethernet-II type value. For example, 861 a protocolDirID value of: 863 8.0.0.0.3.0.0.8.0 865 defines the IP/SNAP protocol. 867 Children of this protocol are named 'snap' followed by the 868 Ethernet-II type value in hexadecimal. The above example would 869 be named: 871 snap 0x0800" 872 ADDRESS-FORMAT 873 "The address format for SNAP is the same as that for LLC" 874 DECODING 875 "SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA 876 and a single control octet will be present. There are then three 877 octets of OUI and two octets of PID. For this encapsulation the 878 OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)." 879 REFERENCE 880 "[TBD]" 882 Draft RMON Protocol Identifiers November 17, 1995 884 ::= { 3 } 886 4.1.4. SNAP over LLC (OUI != 000) Encapsulation 888 vsnap PROTOCOL-IDENTIFIER 889 PARAMETERS { 890 others(1) -- The count of vsnap packets that didn't match 891 -- any children of vsnap enabled in the protocolDirectory 892 } 893 ATTRIBUTES { 894 hasChildren(0), 895 addressRecognitionCapable(1) 896 } 897 DESCRIPTION 898 "This pseudo-protocol handles all SNAP packets which do not have 899 a zero OUI. See 'snap' above for details of those that do." 900 CHILDREN 901 "Children of 'vsnap' are selected by the 3 octet OUI; the PID is 902 not parsed; child protocols are deemed to start with the first 903 octet of the SNAP PID field, and continue to the end of the 904 packet. 906 Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol 907 identifier for 'vsnap', followed by [ 0.a.b.c ] where 'a', 'b' 908 and 'c' are the 3 octets of the OUI field in network order. For 909 example, a protocolDirID value of: 911 8.0.0.0.4.0.1.2.3 913 defines the set of protocols whose OUI is 0x010203. 915 Children are named as 'vsnap' followed by the 3 octets of the OUI 916 as a single hexadecimal value. So the above example would be 917 named: 919 vsnap 0x010203" 920 ADDRESS-FORMAT 921 "The LLC address format is inherited by 'vsnap'. See the 'llc' 922 protocol identifier for more details." 923 DECODING 924 "Same as for 'snap' except the OUI is non-zero." 925 REFERENCE 926 "Same as for 'snap'." 927 ::= { 4 } 929 Draft RMON Protocol Identifiers November 17, 1995 931 4.1.5. Raw 802.3 Encapsulation 933 -- This really only here to support Novell's older encapsulation on 934 -- ethernet-like LANs. Do not create children of this protocol unless 935 -- you are sure that they cannot be handled by the more conventional link 936 -- layers above. 937 raw8023 PROTOCOL-IDENTIFIER 938 PARAMETERS { 939 others(1) -- The count of raw8023 packets that didn't match 940 -- any children of raw8023 enabled in the protocolDirectory 941 } 942 ATTRIBUTES { 943 hasChildren(0), 944 addressRecognitionCapable(1) 945 } 946 DESCRIPTION 947 "This pseudo-protocol describes an 802.3 header (destination, 948 source, length) with no LLC/802.2 header. This encapsulation 949 violates the 802.3 specification in that the 802.2 header is 950 mandated for 802.3 frames. The header is otherwise well formed." 951 CHILDREN 952 "Children of 'raw8023' are identified by the Ethernet-II type 953 field value which they would use if running over the 'snap' or 954 'ether2' link layer protocols. In reality there is no such field 955 in the packet; instead the agent decodes the header and maps it 956 to this value in a protocol specific manner. The child protocol 957 is deemed to start at the first octet after the 802.3 length 958 field (i.e. in the information field). 960 Children of 'raw8023' are encoded as [ 0.0.0.5 ], the protocol 961 identifier for 'raw8023', followed by [ 0.0.a.b ] where 'a' and 962 'b' are the MSB and LSB of the Ethernet-II type. For example, a 963 protocolDirID value of: 965 8.0.0.0.5.0.0.129.55 967 defines the IPX protocol encapsulated directly in 802.3. 969 Children are named 'raw8023' followed by the value of the 970 Ethernet-II type in hexadecimal. The above example would be 971 named: 973 raw8023 0x8137" 974 ADDRESS-FORMAT 975 "The address format is the same as that for 'ether2'." 977 Draft RMON Protocol Identifiers November 17, 1995 979 DECODING 980 "Whenever the 802.3 header indicates LLC a set of protocol 981 specific tests needs to be applied to determine whether this is a 982 'raw8023' packet or a true 802.2 packet. The nature of these 983 tests depends on the active child protocols for 'raw8023' and is 984 beyond the scope of this document." 985 REFERENCE 986 "None - this is a pseudo-protocol." 987 ::= { 5 } 989 4.2. L3 Protocol Identifiers 991 Network layer protocol identifier macros contain additional information 992 about the network layer, and (if present) is found immediately following 993 an L2 layer-identifier in a protocol identifier. 995 The ProtocolDirParameters supported at the network layer are 996 'countsFragments(0)', 'others(1)', and 'tracksSessions(2). An agent may 997 choose to implement a subset of these parameters. 999 The protocol-name should be used for the ProtocolDirDescr field. 1001 The ProtocolDirType ATTRIBUTES used at the network layer are 1002 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose 1003 to implement a subset of these attributes, and therefore limit which 1004 tables the indicated protocol can be present (e.g. protocolDistribution, 1005 nlHost, nlMatrix).. 1007 The following protocol-identifier macro declarations are given for 1008 example purposes only. They are not intended to constitute an exhaustive 1009 list or an authoritative source for any of the protocol information 1010 given. 1012 4.2.1. IP 1014 ip PROTOCOL-IDENTIFIER 1015 PARAMETERS { 1016 countsFragments(0), -- This parameter applies to all child 1017 -- protocols. 1018 others(1) -- The count of ip packets that didn't match 1019 -- any children of ip enabled in the protocolDirectory 1020 } 1021 ATTRIBUTES { 1022 hasChildren(0), 1024 Draft RMON Protocol Identifiers November 17, 1995 1026 addressRecognitionCapable(1) 1027 } 1028 DESCRIPTION 1029 "The protocol identifiers for IP. " 1030 CHILDREN 1031 "Children of IP are defined by the value in the Protocol field, 1032 as defined in the PROTOCOL NUMBERS table within the Assigned 1033 Numbers Document. 1035 The value of the Protocol field is encoded in an octet string as 1036 [ 0.0.0.a ], where 'a' is the protocol field . 1038 Children are named 'ip a' where a is the protocol field value (in 1039 decimal)." 1040 ADDRESS-FORMAT 1041 "4 octets of the IP address, in network byte order. Each ip 1042 packet contains two addresses, the source address and the 1043 destination address." 1044 DECODING 1045 "Note: ether2/ip/ipip4/udp is a different protocolDirID than 1046 ether2/ip/udp, as identified in the protocolDirTable. As such, 1047 two different local protocol index values will be assigned by the 1048 agent. E.g.: 1049 ether2/ip/ipip4/udp 1050 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0 1051 ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 " 1052 REFERENCE 1053 "RFC 791; 1054 The following URL defines the authoritative repository 1055 for the PROTOCOL NUMBERS Table: 1057 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers" 1058 ::= { 1059 ether2 0x0800, 1060 llc 0x08, 1061 snap 0x0800, 1062 ip 4, 1063 ip 94 1064 } 1066 4.2.1.1. Children of IP 1067 Draft RMON Protocol Identifiers November 17, 1995 1069 4.2.1.1.1. ICMP 1071 icmp PROTOCOL-IDENTIFIER 1072 PARAMETERS {} 1073 ATTRIBUTES {} 1074 DESCRIPTION 1075 "Internet Message Control Protocol." 1076 REFERENCE 1077 "RFC-792" 1078 ::= { ip 1 } 1080 4.2.1.1.2. TCP 1082 tcp PROTOCOL-IDENTIFIER 1083 PARAMETERS { 1084 others(1) -- The count of tcp packets that didn't match 1085 -- any children of tcp enabled in the protocolDirectory 1086 } 1087 ATTRIBUTES { 1088 hasChildren(0) 1089 } 1090 DESCRIPTION 1091 "Transmission Control Protocol." 1092 CHILDREN 1093 "Children of TCP are identified by the 16 bit Destination Port 1094 value as specified in RFC 793." 1095 REFERENCE 1096 "RFC 793; 1097 The following URL defines the authoritative repository 1098 for reserved and registered TCP port values: 1100 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 1101 ::= { ip 6 } 1103 4.2.1.1.3. UDP 1105 udp PROTOCOL-IDENTIFIER 1106 PARAMETERS { 1107 others(1) -- The count of udp packets that didn't match 1108 -- any children of udp enabled in the protocolDirectory 1109 } 1110 ATTRIBUTES { 1111 hasChildren(0) 1112 } 1114 Draft RMON Protocol Identifiers November 17, 1995 1116 DESCRIPTION 1117 "User Datagram Protocol." 1118 CHILDREN 1119 "Children of UDP are identified by the 16 bit Destination Port 1120 value as specified in RFC 768." 1121 REFERENCE 1122 "RFC 768; 1123 The following URL defines the authoritative repository 1124 for reserved and registered UDP port values: 1126 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 1127 ::= { ip 17 } 1129 4.2.1.1.3.1. Children of UDP 1131 Note that some of the following protocols can be encapsulated in 1132 protocols other than UDP. The assignment section of each protocol- 1133 identifier macro lists any additional encapsulations. 1135 4.2.1.1.3.1. SNMP 1137 snmp PROTOCOL-IDENTIFIER 1138 PARAMETERS {} 1139 ATTRIBUTES {} 1140 DESCRIPTION 1141 "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 1142 protocol versions. Does not include SNMP trap packets." 1143 REFERENCE 1144 "SNMPv2: RFCs 1441 - 1452; 1145 SNMPv1: RFC 1155, RFC 1157; 1146 SNMP over IPX: RFC 1420; 1147 SNMP over AppleTalk: RFC 1419;" 1148 ::= { 1149 udp 161, 1150 ipx 161 1151 } 1153 4.2.1.1.3.1. SNMPTRAP 1155 snmptrap PROTOCOL-IDENTIFIER 1156 PARAMETERS {} 1157 ATTRIBUTES {} 1158 DESCRIPTION 1159 "Simple Network Management Protocol Trap Port." 1160 REFERENCE 1162 Draft RMON Protocol Identifiers November 17, 1995 1164 "SNMPv2: RFCs 1441 - 1452; 1165 SNMPv1: RFC 1155, RFC 1157; 1166 SNMP over IPX: RFC 1420; 1167 SNMP over AppleTalk: RFC 1419;" 1168 ::= { 1169 udp 162, 1170 ipx 162 1171 } 1173 4.2.1.1.3.1. TFTP 1175 tftp PROTOCOL-IDENTIFIER 1176 PARAMETERS { 1177 tracksSessions(2) 1178 } 1179 ATTRIBUTES {} 1180 DESCRIPTION 1181 "Trivial File Transfer Protocol; Only the first packet of each 1182 TFTP transaction will be sent to port 69. If the tracksSessions 1183 attribute is set, then packets for each TFTP transaction will be 1184 attributed to tftp, instead of the unregistered port numbers that 1185 will be encoded in subsequent packets." 1186 REFERENCE 1187 "RFC 1350; 1188 TFTP Option Extension (RFC 1782) 1189 TFTP Blocksize Option (RFC 1783) 1190 TFTP Timeout Interval and Transfer Size Options (RFC 1784) 1191 TFTP Option Negotiation Analysis (RFC 1785)" 1192 ::= { udp 69 } 1194 4.2.2. IPX 1196 ipx PROTOCOL-IDENTIFIER 1197 PARAMETERS { 1198 others(1) -- The count of ipx packets that didn't match 1199 -- any children of ipx enabled in the protocolDirectory 1200 } 1201 ATTRIBUTES { 1202 hasChildren(0), 1203 addressRecognitionCapable(1) 1204 } 1205 DESCRIPTION 1206 "Novell IPX" 1207 CHILDREN 1208 "Children of IPX are defined by the 16 bit value of the 1210 Draft RMON Protocol Identifiers November 17, 1995 1212 Destination Socket field. The value is encoded into an octet 1213 string as [ 0.0.a.b ], where 'a' and 'b' are the network byte 1214 order encodings of the MSB and LSB of the destination socket 1215 field." 1216 ADDRESS-FORMAT 1217 "4 bytes of Network number followed by the 6 bytes Host address 1218 each in network byte order". 1219 DECODING 1220 "" 1221 REFERENCE 1222 "Novell [TBD]" 1223 ::= { 1224 ether2 0x8137, -- 0.0.129.55 1225 llc 0xe0e003, -- 0.224.224.3 1226 snap 0x8137, -- 0.0.129.55 1227 raw8023 0x8137 -- 0.0.129.55 1228 } 1230 4.2.3. ARP 1232 arp PROTOCOL-IDENTIFIER 1233 PARAMETERS {} 1234 ATTRIBUTES {} 1235 DESCRIPTION 1236 "An 802.3 header followed immediately by a payload (i.e. no TYPE 1237 field)." 1238 REFERENCE 1239 "RFC 826" 1240 ::= { 1241 ether2 0x806, -- [ 0.0.8.6 ] 1242 snap 0x806 1243 } 1245 4.2.4. IDP 1247 idp PROTOCOL-IDENTIFIER 1248 PARAMETERS { 1249 others(1) -- The count of idp packets that didn't match 1250 -- any children of idp enabled in the protocolDirectory 1251 } 1252 ATTRIBUTES { 1253 hasChildren(0), 1254 addressRecognitionCapable(1) 1255 } 1257 Draft RMON Protocol Identifiers November 17, 1995 1259 DESCRIPTION 1260 "Xerox IDP" 1261 CHILDREN 1262 "Children of IDP are defined by the 8 bit value of the Packet 1263 type field. The value is encoded into an octet string as [ 1264 0.0.0.a ], where 'a' is the value of the packet type field in 1265 network byte order. 1266 ADDRESS-FORMAT 1267 "4 bytes of Network number followed by the 6 bytes Host address 1268 each in network byte order". 1269 REFERENCE 1270 "Xerox Corporation, Document XNSS 028112, 1981" 1271 ::= { 1272 ether2 0x600, -- [ 0.0.6.0 ] 1273 snap 0x600 1274 } 1276 4.2.5. Appletalk ARP 1278 atalkarp PROTOCOL-IDENTIFIER 1279 PARAMETERS {} 1280 ATTRIBUTES {} 1281 DESCRIPTION 1282 "Appletalk Address Resolution Protocol." 1283 REFERENCE 1284 "AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A." 1285 ::= { 1286 ether2 0x80F3, -- [ 0.0.128.243 ] 1287 snap 0x80F3 1288 } 1290 4.2.6. Appletalk 1292 atalk PROTOCOL-IDENTIFIER 1293 PARAMETERS { 1294 others(1) -- The count of ether2 packets that didn't match 1295 -- any children of ether2 enabled in the protocolDirectory 1296 } 1297 ATTRIBUTES { 1298 hasChildren(0), 1299 addressRecognitionCapable(1) 1300 } 1301 DESCRIPTION 1302 "AppleTalk Protocol." 1304 Draft RMON Protocol Identifiers November 17, 1995 1306 CHILDREN 1307 "Children of ATALK are defined by the 8 bit value of the DDP type 1308 field. The value is encoded into an octet string as [ 0.0.0.a ], 1309 where 'a' is the value of the DDP type field in network byte 1310 order. 1311 ADDRESS-FORMAT 1312 "2 bytes of Network number followed by 1 byte of node id each in 1313 network byte order". 1314 REFERENCE 1315 "AppleTalk Phase 2 Protocol Specification, document ADPA #C0144LL/A." 1316 ::= { 1317 ether2 0x809b, -- [ 0.0.128.155 ] 1318 vsnap 0x809b 1319 } 1321 Draft RMON Protocol Identifiers November 17, 1995 1323 5. Acknowledgements 1325 This document was produced by the IETF RMONMIB Working Group. 1327 The authors wish to thank the following people for their contributions 1328 to this document: 1330 Anil Singhal 1331 Frontier Software Development, Inc. 1332 anil@frontier.com 1334 Jeanne Haney 1335 Coronet Systems 1336 jeanne@coronet.com 1338 Dan Hansen 1339 Network General Corp. 1340 danh@ngc.com 1342 Draft RMON Protocol Identifiers November 17, 1995 1344 6. References 1346 [RFC1212] 1347 Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", 1348 RFC 1212, Performance Systems International, Hughes LAN Systems, 1349 March 1991. 1351 [RFC1213] 1352 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1353 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1354 RFC 1213, Hughes LAN Systems, Performance Systems International, 1355 March 1991. 1357 [RFC1442] 1358 Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1359 of Management Information for version 2 of the Simple Network 1360 Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes 1361 LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1362 University, April 1993. 1364 [RFC1445] 1365 Galvin, J., and K. McCloghrie, "Administrative Model for version 2 1366 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, 1367 Trusted Information Systems, Hughes LAN Systems, April 1993. 1369 [RFC1448] 1370 Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1371 Operations for version 2 of the Simple Network Management Protocol 1372 (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover 1373 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 1375 [RFC1700] 1376 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1377 USC/Information Sciences Institute, October 1994. 1379 [RFC1757] 1380 S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie 1381 Mellon University, February 1995. 1383 [RFC1800] 1384 Postel, J., Editor, "Internet Official Protocol Standards", STD 1, 1385 RFC 1800, IAB, July 1995. 1387 [RMON2] 1388 S. Waldbusser, "Remote Network Monitoring MIB Version 2", draft- 1390 Draft RMON Protocol Identifiers November 17, 1995 1392 ietf-rmonmib-rmon2-02.txt, International Network Services, October 1393 1995. 1395 Draft RMON Protocol Identifiers November 17, 1995 1397 7. Security Considerations 1399 Security issues are not discussed in this memo. 1401 8. Authors' Addresses 1403 Andy Bierman 1404 Bierman Consulting 1405 1200 Sagamore Lane 1406 Ventura, CA 93001 1407 Phone: 805-648-2028 1408 Email: abierman@west.net 1410 Robin Iddon 1411 AXON Networks, Inc. 1412 [TBD] 1413 Phone: [TBD] 1414 Email: robini@axon.com 1416 Draft RMON Protocol Identifiers November 17, 1995 1418 Table of Contents 1420 1 Introduction .................................................... 2 1421 1.1 The SNMPv2 Network Management Framework ....................... 2 1422 1.1.1 Object Definitions .......................................... 2 1423 2 Overview ........................................................ 3 1424 2.1 Terms ......................................................... 3 1425 2.2 Relationship to the Remote Network Monitoring MIB ............. 5 1426 2.3 Relationship to the Other MIBs ................................ 5 1427 3 Protocol Identifier Encoding .................................... 6 1428 3.1 ProtocolDirTable INDEX Format Examples ........................ 8 1429 3.2 Protocol Identifier Macro Format .............................. 9 1430 3.2.1 Mapping of the Protocol Name ................................ 9 1431 3.2.2 Mapping of the PARAMETERS Clause ............................ 10 1432 3.2.2.1 Mapping of the 'countsFragments(0)' BIT ................... 11 1433 3.2.2.2 Mapping of the 'others(1)' BIT ............................ 12 1434 3.2.2.2.1 Relationship to the protocolDirTable .................... 12 1435 3.2.2.3 Mapping of the 'tracksSessions(2)' BIT .................... 13 1436 3.2.3 Mapping of the ATTRIBUTES Clause ............................ 13 1437 3.2.4 Mapping of the DESCRIPTION Clause ........................... 14 1438 3.2.5 Mapping of the CHILDREN Clause .............................. 14 1439 3.2.6 Mapping of the ADDRESS-FORMAT Clause ........................ 15 1440 3.2.7 Mapping of the DECODING Clause .............................. 15 1441 3.2.8 Mapping of the REFERENCE Clause ............................. 15 1442 3.2.9 Evaluating a Protocol-Identifier INDEX ...................... 16 1443 4 Protocol Identifier Macro Examples .............................. 17 1444 4.1 L2 Protocol Identifiers ....................................... 17 1445 4.1.1 Ether2 Encapsulation ........................................ 18 1446 4.1.2 LLC Encapsulation ........................................... 19 1447 4.1.3 SNAP over LLC (OUI=000) Encapsulation ....................... 21 1448 4.1.4 SNAP over LLC (OUI != 000) Encapsulation .................... 22 1449 4.1.5 Raw 802.3 Encapsulation ..................................... 23 1450 4.2 L3 Protocol Identifiers ....................................... 24 1451 4.2.1 IP .......................................................... 24 1452 4.2.1.1 Children of IP ............................................ 25 1453 4.2.1.1.1 ICMP .................................................... 26 1454 4.2.1.1.2 TCP ..................................................... 26 1455 4.2.1.1.3 UDP ..................................................... 26 1456 4.2.1.1.3.1 Children of UDP ....................................... 27 1457 4.2.1.1.3.1 SNMP .................................................. 27 1458 4.2.1.1.3.1 SNMPTRAP .............................................. 27 1459 4.2.1.1.3.1 TFTP .................................................. 28 1460 4.2.2 IPX ......................................................... 28 1461 4.2.3 ARP ......................................................... 29 1462 Draft RMON Protocol Identifiers November 17, 1995 1464 4.2.4 IDP ......................................................... 29 1465 4.2.5 Appletalk ARP ............................................... 30 1466 4.2.6 Appletalk ................................................... 30 1467 5 Acknowledgements ................................................ 32 1468 6 References ...................................................... 33 1469 7 Security Considerations ......................................... 35 1470 8 Authors' Addresses .............................................. 35