idnits 2.17.1 draft-ietf-rmonmib-rmonprot-02.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-25) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 38) being 59 lines 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 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 553 has weird spacing: '...agments high...' == Line 557 has weird spacing: '...essions cor...' == Line 849 has weird spacing: '...set for the '...' == Line 1655 has weird spacing: '...fffffff defi...' == Line 1656 has weird spacing: '...fffffff defi...' == (6 more instances...) -- 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 (22 May 1996) is 10200 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC1813' is mentioned on line 1709, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1419 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1725 (Obsoleted by RFC 1939) ** Obsolete normative reference: RFC 1757 (Obsoleted by RFC 2819) ** Obsolete normative reference: RFC 1782 (Obsoleted by RFC 2347) ** Obsolete normative reference: RFC 1783 (Obsoleted by RFC 2348) ** Obsolete normative reference: RFC 1784 (Obsoleted by RFC 2349) ** Obsolete normative reference: RFC 1800 (Obsoleted by RFC 1880) ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Downref: Normative reference to an Informational RFC: RFC 1945 -- Possible downref: Normative reference to a draft: ref. 'RMON2' Summary: 29 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft RMON Protocol Identifiers May 1996 4 Remote Network Monitoring MIB Protocol Identifiers 5 7 22 May 1996 9 Andy Bierman 10 Cisco Systems Inc. 11 abierman@cisco.com 13 Robin Iddon 14 AXON Networks, Inc. 15 robini@axon.com 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Draft RMON Protocol Identifiers May 1996 36 1. Introduction 38 This memo defines an experimental portion of the Management Information 39 Base (MIB) for use with network management protocols in the Internet 40 community. In particular, it describes the algorithms required to 41 identify different protocol encapsulations managed with the Remote 42 Network Monitoring MIB Version 2 [RMON2]. Although related to the 43 original Remote Network Monitoring MIB [RFC1757], this document refers 44 only to objects found in the RMON-2 MIB. 46 Draft RMON Protocol Identifiers May 1996 48 2. The SNMP Network Management Framework 50 The SNMP Network Management Framework presently consists of three major 51 components. They are: 53 o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for 54 describing and naming objects for the purpose of management. 56 o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed 57 objects for the Internet suite of protocols. 59 o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the 60 protocol for accessing managed information. 62 Textual conventions are defined in RFC 1903 [RFC1903], and conformance 63 statements are defined in RFC 1904 [RFC1904]. 65 The Framework permits new objects to be defined for the purpose of 66 experimentation and evaluation. 68 2.1. Object Definitions 70 Managed objects are accessed via a virtual information store, termed the 71 Management Information Base or MIB. Objects in the MIB are defined 72 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 73 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 74 an administratively assigned name. The object type together with an 75 object instance serves to uniquely identify a specific instantiation of 76 the object. For human convenience, we often use a textual string, 77 termed the descriptor, to refer to the object type. 79 Draft RMON Protocol Identifiers May 1996 81 3. Overview 83 The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to 84 globally identify individual protocol encapsulations in the 85 protocolDirTable. 87 This guide contains algorithms and examples of protocol identifier 88 encapsulations for use as INDEX values in the protocolDirTable. 90 This document is not intended to be an authoritative reference on the 91 protocols described herein. Refer to the Official Internet Standards 92 document [RFC1800], the Assigned Numbers document [RFC1700], or other 93 appropriate RFCs, IEEE documents, etc. for complete and authoritative 94 protocol information. 96 3.1. Terms 98 Several terms are used throughout this document, as well as in the 99 RMON-2 MIB [RMON2], that should be introduced: 101 layer-identifier: 102 An octet string fragment representing a particular protocol 103 encapsulation layer. A string fragment identifying a particular 104 protocol encapsulation layer. This string is exactly four octets, 105 (except for the 'vsnap' base-layer identifier, which is exactly 106 eight octets) encoded in network byte order. A particular protocol 107 encapsulation can be identified by starting with a base layer 108 encapsulation (see the 'Base Protocol Identifiers' section for more 109 detail), and following the encoding rules specified in the CHILDREN 110 clause and assignment section for that layer. Then repeat for each 111 identified layer in the encapsulation. (See section 4.2.10 112 'Evaluating a Protocol-Identifier INDEX' for more detail.) 114 protocol: 115 A particular protocol layer, as specified by encoding rules in this 116 document. Usually refers to a single layer in a given 117 encapsulation. Note that this term is sometimes used in the RMON-2 118 MIB [RMON2] to name a fully-specified protocol-identifier string. 119 In such a case, the protocol-identifier string is named for its 120 upper-most layer. A named protocol may also refer to any 121 encapsulation of that protocol. 123 Draft RMON Protocol Identifiers May 1996 125 protocol-identifier string: 126 An octet string representing a particular protocol encapsulation, 127 as specified by encoding rules in this document. This string is 128 identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A 129 protocol-identifier string is composed of one or more layer- 130 identifiers. 132 protocol-identifier macro: 133 A group of formatted text describing a particular protocol layer, 134 as used within the RMON-2 MIB [RMON2]. The macro serves several 135 purposes: 137 - Name the protocol for use within the RMON-2 MIB [RMON2]. 138 - Describe how the protocol is encoded into an octet string. 139 - Describe how child protocols are identified (if applicable), 140 and encoded into an octet string. 141 - Describe which protocolDirParameters are allowed for the protocol. 142 - Describe how the associated protocolDirType object is encoded 143 for the protocol. 144 - Provide reference(s) to authoritative documentation for the 145 protocol. 147 protocol-variant-identifier macro: 148 A group of formatted text describing a particular protocol layer, 149 as used within the RMON-2 MIB [RMON2]. This protocol is a variant 150 of a well known encapsulation that may be present in the 151 protocolDirTable. This macro is used to document the working group 152 assigned protocols, which are needed to identify protocols which 153 cannot be practically identified by examination of 'appropriate 154 network traffic' (e.g. the packets which carry them). All other 155 protocols (which can be identified by examination of appropriate 156 network traffic) should be documented using the protocol-identifier 157 macro. A protocol-variant-identifier is documented using the 158 protocol-variant version of the protocol-identifier macro. 160 protocol-parameter: 161 A single octet, corresponding to a specific layer-identifier in the 162 protocol-identifier. This octet is a bit-mask indicating special 163 functions or capabilities that this agent is providing for the 164 corresponding protocol. 166 protocol-parameters string: 167 An octet string, which contains one protocol-parameter for each 168 layer-identifier in the protocol-identifier. See the section 169 'Mapping of the PARAMETERS Clause' for more detail. This string is 171 Draft RMON Protocol Identifiers May 1996 173 identified in the RMON-2 MIB [RMON2] as the protocolDirParameters 174 object. 176 protocolDirTable INDEX: 177 A protocol-identifier and protocol-parameters octet string pair 178 that have been converted to an INDEX value, according to the 179 encoding rules in in section 7.7 of RFC 1902 [RFC1902]. 181 pseudo-protocol: 182 A convention or algorithm used only within this document for the 183 purpose of encoding protocol-identifier strings. 185 3.2. Relationship to the Remote Network Monitoring MIB 187 This document is intended to identify possible string values for the 188 OCTET STRING objects protocolDirID and protocolDirParameters. Tables in 189 the new Protocol Distribution, Host, and Matrix groups use a local 190 INTEGER INDEX, in order to remain unaffected by changes in this 191 document. Only the protocolDirTable uses the strings (protocolDirID and 192 protocolDirParameters) described in this document. 194 This document is not intended to limit the protocols that may be 195 identified for counting in the RMON-2 MIB. Many protocol encapsulations, 196 not explicitly identified in this document, may be present in an actual 197 implementation of the protocolDirTable. Also, implementations of the 198 protocolDirTable may not include all the protocols identified in the 199 example section below. 201 This document is intentionally separated from the MIB objects to allow 202 frequent updates to this document without any republication of MIB 203 objects. Protocol Identifier macros submitted from the RMON working 204 group and community at large (to the RMONMIB WG mailing list at 205 'rmonmib@cisco.com') will be collected and added to this document, 206 approximately three times a year. Macros submissions will be collected 207 in the RMONMIB WG archive under the directory 208 "ftp://ftp.cisco.com/ftp/rmonmib/rmon2_pi_macros/" or in the mailing 209 list message archive file "ftp://ftp.cisco.com/ftp/rmonmib/rmonmib". 211 This document does not discuss auto-discovery and auto-population of the 212 protocolDirTable. This functionality is not explicitly defined by the 213 RMON standard. An agent should populate the directory with 'interesting' 214 protocols--depending on the intended applications. 216 Draft RMON Protocol Identifiers May 1996 218 3.3. Relationship to the Other MIBs 220 The RMON Protocol Identifiers document is intended for use with the 221 protocolDirTable within the RMON MIB. It is not relevant to any other 222 MIB, or intended for use with any other MIB. 224 Draft RMON Protocol Identifiers May 1996 226 4. Protocol Identifier Encoding 228 The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and 229 protocolDirParameters. To encode the table index, each variable-length 230 string is converted to an OBJECT IDENTIFIER fragment, according to the 231 encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index 232 fragments are simply concatenated. (Refer to figures 1a - 1d below for 233 more detail.) 235 The first OCTET STRING (protocolDirID) is composed of one or more 4- 236 octet "layer-identifiers". The entire string uniquely identifies a 237 particular protocol encapsulation tree. The second OCTET STRING, 238 (protocolDirParameters) which contains a corresponding number of 1-octet 239 protocol-specific parameters, one for each 4-octet layer-identifier in 240 the first string. 242 A protocol layer is normally identified by a single 32-bit value. Each 243 layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as 244 four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of 245 the 32-bit value in network byte order. If a particular protocol layer 246 cannot be encoded into 32 bits, (except for the 'vsnap' base layer) then 247 it must be defined as a 'wgAssigned' protocol (see below for details on 248 working group assigned protocols). 250 Draft RMON Protocol Identifiers May 1996 252 The following figures show the differences between the OBJECT IDENTIFIER 253 and OCTET STRING encoding of the protocol identifier string. 255 Fig. 1a 256 protocolDirTable INDEX Format 257 ----------------------------- 259 +---+--------------------------+---+---------------+ 260 | c ! | c ! protocolDir | 261 | n ! protocolDirID | n ! Parameters | 262 | t ! | t ! | 263 +---+--------------------------+---+---------------+ 265 Fig. 1b 266 protocolDirTable OCTET STRING Format 267 ------------------------------------ 269 protocolDirID 270 +----------------------------------------+ 271 | | 272 | 4 * N octets | 273 | | 274 +----------------------------------------+ 276 protocolDirParameters 277 +----------+ 278 | | 279 | N octets | 280 | | 281 +----------+ 283 Fig. 1c 284 protocolDirTable INDEX Format Example 285 ------------------------------------- 287 protocolDirID protocolDirParameters 288 +---+--------+--------+--------+--------+---+---+---+---+---+ 289 | c | proto | proto | proto | proto | c |par|par|par|par| 290 | n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5| 291 | t |(+flags)| | | | t |se | | | | 292 +---+--------+--------+--------+--------+---+---+---+---+---+ subOID 293 | 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count 295 where N is the number of protocol-layer-identifiers required 296 for the entire encapsulation of the named protocol. Note that 298 Draft RMON Protocol Identifiers May 1996 300 the 'vsnap' base layer identifier is encoded into 8 sub-identifiers, 301 All other protocol layers are either encoded into 4 sub-identifiers 302 or encoded as a 'wgAssigned' protocol. 304 Fig. 1d 305 protocolDirTable OCTET STRING Format Example 306 -------------------------------------------- 308 protocolDirID 309 +--------+--------+--------+--------+ 310 | proto | proto | proto | proto | 311 | base | L3 | L4 | L5 | 312 | | | | | 313 +--------+--------+--------+--------+ octet 314 | 4 or 8 | 4 | 4 | 4 | count 316 protocolDirParameters 317 +---+---+---+---+ 318 |par|par|par|par| 319 |ba-| L3| L4| L5| 320 |se | | | | 321 +---+---+---+---+ octet 322 |1/2| 1 | 1 | 1 | count 324 where N is the number of protocol-layer-identifiers required 325 for the entire encapsulation of the named protocol. Note that 326 the 'vsnap' base layer identifier is encoded into 8 327 protocolDirID sub-identifiers and 2 protocolDirParameters 328 sub-identifiers. 330 Although this example indicates four encapsulated protocols, in 331 practice, any non-zero number of layer-identifiers may be present, 332 theoretically limited only by OBJECT IDENTIFIER length restrictions, as 333 specified in section 3.5 of RFC 1902 [RFC1902]. 335 Note that these two strings would not be concatenated together if ever 336 returned in a GetResponse PDU, since they are different MIB objects. 337 However, protocolDirID and protocolDirParameters are not currently 338 readable MIB objects. 340 Draft RMON Protocol Identifiers May 1996 342 4.1. ProtocolDirTable INDEX Format Examples 344 -- HTTP; fragments counted from IP and above 345 ether2.ip.tcp.www-http = 346 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0 348 -- SNMP over UDP/IP over SNAP 349 snap.ip.udp.snmp = 350 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 352 -- SNMP over IPX over SNAP 353 snap.ipx.snmp = 354 12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0 356 -- SNMP over IPX over raw8023 357 -- wgAssigned(ipxOverRaw8023(1)).snmp = 358 12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0 360 -- IPX over LLC 361 llc.ipx = 362 8.0.0.0.2.0.224.224.3.2.0.0 364 -- SNMP over UDP/IP over any link layer 365 -- wildcard-ether2.ip.udp.snmp 366 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 368 -- IP over any link layer; base encoding is IP over ether2 369 -- wildcard-ether2.ip 370 8.2.1.0.1.0.0.8.0.2.0.0 372 -- Appletalk Phase 2 over ether2 373 -- ether2.atalk 374 8.0.0.0.1.0.0.128.155.2.0.0 376 -- Appletalk Phase 2 over vsnap 377 -- vsnap(apple).atalk 378 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0 380 4.2. Protocol Identifier Macro Format 382 The following example is meant to introduce the protocol-identifier 383 macro. (The syntax is not quite ASN.1.) This macro is used to represent 384 both protocols and protocol-variants. 386 Draft RMON Protocol Identifiers May 1996 388 If the 'VariantOfPart' component of the macro is present, then the macro 389 represents a protocol-variant instead of a protocol. A protocol- 390 variant-identifier is used only for working group assigned protocols, 391 enumerated under the 'wgAssigned' base-layer. 393 RMON-PROTOCOL-IDENTIFIER MACRO ::= 394 BEGIN 395 PIMacroName "PROTOCOL-IDENTIFIER" 396 VariantOfPart 397 "PARAMETERS" ParamPart 398 "ATTRIBUTES" AttrPart 399 "DESCRIPTION" Text 400 ChildDescrPart 401 AddrDescrPart 402 DecodeDescrPart 403 ReferPart 404 "::=" "{" EncapsPart "}" 406 PIMacroName ::= 407 identifier 409 VariantOfPart ::= 410 "VARIANT-OF" identifier | empty 412 ParamPart ::= 413 "{" ParamList "}" 415 ParamList ::= 416 Params | empty 418 Params ::= 419 Param | Params "," Param 421 Param ::= 422 identifier "(" nonNegativeNumber ")" 424 AttrPart ::= 425 "{" AttrList "}" 427 AttrList ::= 428 Attrs | empty 430 Attrs ::= 431 Attr | Attrs "," Attr 433 Draft RMON Protocol Identifiers May 1996 435 Attr ::= 436 identifier "(" nonNegativeNumber ")" 438 ChildDescrPart ::= 439 "CHILDREN" Text | empty 441 AddrDescrPart ::= 442 "ADDRESS-FORMAT" Text | empty 444 DecodeDescrPart ::= 445 "DECODING" Text | empty 447 ReferPart ::= 448 "REFERENCE" Text | empty 450 EncapsPart ::= 451 "{" Encaps "}" 453 Encaps ::= 454 Encap | Encaps "," Encap 456 Encap ::= 457 BaseEncap | NormalEncap | VsnapEncap | WgEncap 459 BaseEncap ::= 460 nonNegativeNumber 462 NormalEncap ::= 463 identifier nonNegitiveNumber 465 VsnapEncap ::= 466 identifier "(" nonNegativeNumber ")" nonNegativeNumber 468 WgEncap ::= 469 "wgAssigned" nonNegativeNumber 470 | "wgAssigned" identifier 471 | "wgAssigned" identifier "(" nonNegativeNumber ")" 473 Text ::= 474 """" string """" 475 END 477 Draft RMON Protocol Identifiers May 1996 479 4.2.1. Mapping of the Protocol Name 481 The 'PIMacroName' value should be a lower-case ASCII string, and contain 482 the name or acronym identifying the protocol. NMS applications may 483 treat protocol names as case-insensitive strings, and agent 484 implementations must make sure the protocolDirTable does not contain any 485 instances of the protocolDirDescr object which differ only in the case 486 of one of more letters (if the identifiers are intended to represent 487 different protocols). 489 It is possible that different encapsulations of the same protocol (which 490 are represented by different entries in the protocolDirTable) will be 491 assigned the same protocol name. 493 A protocol name should match the "most well-known" name or acronym for 494 the indicated protocol. For example, the document indicated by the URL: 496 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 498 defines IP Protocol field values, so protocol-identifier macros for 499 children of IP should be given names consistent with the protocol names 500 found in this authoritative document. 502 4.2.2. Mapping of the VARIANT-OF Clause 504 This clause is present for working group assigned protocols only. It 505 identifies the protocol-identifier macro that most closely represents 506 this particular protocol, and is known as the "reference protocol". (A 507 protocol-identifier macro must exist for the reference protocol.) When 508 this clause is present in a protocol-identifier macro, the macro is 509 called a 'protocol-variant-identifier'. 511 Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol- 512 identifier macro should not be duplicated in the protocol-variant- 513 identifier macro, if the 'variant' protocols' semantics are identical 514 for a given clause. 516 Since the PARAMETERS and ATTRIBUTES clauses must be present in a 517 protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e. 518 "PARAMETERS {}") must be present in a protocol-variant-identifier macro, 519 and the 'ParamPart' and 'AttrPart' found in the reference protocol- 520 identifier macro examined instead. 522 Draft RMON Protocol Identifiers May 1996 524 Note that if a 'wgAssigned' protocol is defined that is not a variant of 525 any other documented protocol, then the protocol-identifier macro should 526 be used instead of the protocol-variant-identifier version of the macro. 528 4.2.3. Mapping of the PARAMETERS Clause 530 The protocolDirParameters object provides an NMS the ability to turn on 531 and off expensive probe resources. An agent may support a given 532 parameter all the time, not at all, or subject to current resource load. 534 The PARAMETERS clause is a list of bit definitions which can be directly 535 encoded into the associated ProtocolDirParameters octet in network byte 536 order. Zero or more bit definitions may be present. Only bits 0-7 are 537 valid encoding values. This clause defines the entire BIT set allowed 538 for a given protocol. A conforming agent may choose to implement a 539 subset of zero or more of these PARAMETERS. 541 By convention, the following common bit definitions are used by 542 different protocols. These bit positions must not be used for other 543 parameters. They should be reserved if not used by a given protocol. 544 Bits are encoded in network-byte order. 546 Draft RMON Protocol Identifiers May 1996 548 Table 3.1 Reserved PARAMETERS Bits 549 ------------------------------------ 551 Bit Name Description 552 --------------------------------------------------------------------- 553 0 countsFragments higher-layer protocols encapsulated within 554 this protocol will be counted correctly even 555 if this protocol fragments the upper layers 556 into multiple packets. 557 1 tracksSessions correctly attributes all packets of a protocol 558 which starts sessions on well known ports or 559 sockets and then transfers them to dynamically 560 assigned ports or sockets thereafter (e.g. TFTP). 562 The PARAMETERS clause must be present in all protocol-identifier macro 563 declarations, but may be equal to zero (empty). Note that an NMS must 564 determine if a given PARAMETER bit is supported by attempting to create 565 the desired protocolDirEntry The associated ATTRIBUTE bits for 566 'countsFragments' and 'tracksSessions' do not exist. 568 4.2.3.1. Mapping of the 'countsFragments(0)' BIT 570 This bit indicates whether the probe is correctly attributing all 571 fragmented packets of the specified protocol, even if individual frames 572 carrying this protocol cannot be identified as such. Note that the 573 probe is not required to actually present any re-assembled datagrams 574 (for address-analysis, filtering, or any other purpose) to the NMS. 576 This bit may only be set in a protocolDirParameters octet which 577 corresponds to a protocol that supports fragmentation and reassembly in 578 some form. Note that TCP packets are not considered 'fragmented-streams' 579 and so TCP is not eligible. 581 This bit may be set in at most one protocolDirParameters octet within a 582 protocolDirTable INDEX. 584 4.2.3.2. Mapping of the 'tracksSessions(1)' BIT 586 The 'tracksSessions(1)' bit indicates whether frames which are part of 587 remapped-sessions (e.g. TFTP download sessions) are correctly counted by 588 the probe. For such a protocol, the probe must usually analyze all 589 Draft RMON Protocol Identifiers May 1996 591 packets received on the indicated interface, and maintain some state 592 information, (e.g. the remapped UDP port number for TFTP). 594 The semantics of the 'tracksSessions' parameter are independent of the 595 other protocolDirParameters definitions, so this parameter may be 596 combined with any other legal parameter configurations. 598 4.2.4. Mapping of the ATTRIBUTES Clause 600 The protocolDirType object provides an NMS with an indication of a 601 probe's capabilities for decoding a given protocol, or the general 602 attributes of the particular protocol. 604 The ATTRIBUTES clause is a list of bit definitions which are encoded 605 into the associated instance of ProtocolDirType. The BIT definitions are 606 specified in the SYNTAX clause of the protocolDirType MIB object. 608 Draft RMON Protocol Identifiers May 1996 610 Table 3.2 Reserved ATTRIBUTES Bits 611 ------------------------------------ 613 Bit Name Description 614 --------------------------------------------------------------------- 615 0 hasChildren indicates that there may be children of 616 this protocol defined in the protocolDirTable 617 (by either the agent or the manager). 618 1 addressRecognitionCapable 619 indicates that this protocol can be used 620 to generate host and matrix table entries. 622 The ATTRIBUTES clause must be present in all protocol-identifier macro 623 declarations, but may be empty. 625 4.2.5. Mapping of the DESCRIPTION Clause 627 The DESCRIPTION clause provides a textual description of the protocol 628 identified by this macro. Notice that it should not contain details 629 about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and 630 REFERENCE clauses. 632 The DESCRIPTION clause must be present in all protocol-identifier macro 633 declarations. 635 4.2.6. Mapping of the CHILDREN Clause 637 The CHILDREN clause provides a description of child protocols for 638 protocols which support them. It has three sub-sections: 640 - Details on the field(s)/value(s) used to select the child protocol, 641 and how that selection process is performed 643 - Details on how the value(s) are encoded in the protocol identifier 644 octet string 646 - Details on how child protocols are named with respect to their 647 parent protocol label(s) 649 The CHILDREN clause must be present in all protocol-identifier macro 650 declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES 651 clause. 653 Draft RMON Protocol Identifiers May 1996 655 4.2.7. Mapping of the ADDRESS-FORMAT Clause 657 The ADDRESS-FORMAT clause provides a description of the OCTET-STRING 658 format(s) used when encoding addresses. 660 This clause must be present in all protocol-identifier macro 661 declarations in which the 'addressRecognitionCapable(1)' BIT is set in 662 the ATTRIBUTES clause. 664 4.2.8. Mapping of the DECODING Clause 666 The DECODING clause provides a description of the decoding procedure for 667 the specified protocol. It contains useful decoding hints for the 668 implementor, but should not over-replicate information in documents 669 cited in the REFERENCE clause. It might contain a complete description 670 of any decoding information required. 672 For 'extensible' protocols ('hasChildren(0)' BIT set) this includes 673 offset and type information for the field(s) used for child selection as 674 well as information on determining the start of the child protocol. 676 For 'addressRecognitionCapable' protocols this includes offset and type 677 information for the field(s) used to generate addresses. 679 The DECODING clause is optional, and may be omitted if the REFERENCE 680 clause contains pointers to decoding information for the specified 681 protocol. 683 4.2.9. Mapping of the REFERENCE Clause 685 If a publicly available reference document exists for this protocol it 686 should be listed here. Typically this will be a URL if possible; if not 687 then it will be the name and address of the controlling body. 689 The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the 690 amount of information which may currently be obtained from an 691 'authoritative' document, such as the Assigned Numbers document 692 [RFC1700]. Any duplication or paraphrasing of information should be 693 brief and consistent with the authoritative document. 695 The REFERENCE clause is optional, but should be implemented if an 696 authoritative reference exists for the protocol (especially for standard 697 protocols). 699 Draft RMON Protocol Identifiers May 1996 701 4.2.10. Evaluating a Protocol-Identifier INDEX 703 The following evaluation is done after protocolDirTable INDEX value has 704 been converted into two OCTET STRINGs according to the INDEX encoding 705 rules specified in the SMI [RFC1902]. 707 Protocol-identifiers are evaluated left to right, starting with the 708 protocolDirID, which length should be evenly divisible by four. The 709 protocolDirParameters length should be exactly one quarter of the 710 protocolDirID string length. 712 Protocol-identifier parsing starts with the base layer identifier, which 713 must be present, and continues for one or more upper layer identifiers, 714 until all OCTETs of the protocolDirID have been used. Layers may not be 715 skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can 716 not exist. 718 The base-layer-identifier also contains a 'special function identifier' 719 which may apply to the rest of the protocol identifier. 721 Wild-carding at the base layer within a protocol encapsulation is the 722 only supported special function at this time. Refer to the 'Base 723 Protocol Identifiers' section for wildcard encoding rules. 725 After the protocol-tree identified in protocolDirID has been parsed, 726 each parameter bit-mask (one octet for each 4-octet layer-identifier) is 727 evaluated, and applied to the corresponding protocol layer. 729 A protocol-identifier label may map to more than one value. For 730 instance, 'ip' maps to 5 distinct values, one for each supported 731 encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers'), 733 It is important to note that these macros are conceptually expanded at 734 implementation time, not at run time. 736 If all the macros are expanded completely by substituting all possible 737 values of each label for each child protocol, a list of all possible 738 protocol-identifiers is produced. So 'ip' would result in 5 distinct 739 protocol-identifiers. Likewise each child of 'ip' would map to at least 740 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, 741 ip over LLC, etc.). 743 Draft RMON Protocol Identifiers May 1996 745 5. Protocol Identifier Macros 747 The following PROTOCOL IDENTIFIER macros can be used to construct 748 protocolDirID and protocolDirParameters strings. 750 The sections defining protocol examples are intended to grow over 751 subsequent releases. Minimal protocol support is included at this time. 752 (Refer to section 3.2 for details on the protocol macro update 753 procedure.) 755 An identifier is encoded by constructing the base-identifier, then 756 adding one layer-identifier for each encapsulated protocol. 758 5.1. Base Identifier Encoding 760 The first layer encapsulation is called the base identifier and it 761 contains optional protocol-function information and the base layer (e.g. 762 MAC layer) enumeration value used in this protocol identifier. 764 The base identifier is encoded as four octets as shown in figure 2. 766 Fig. 2 767 base-identifier format 768 +---+---+---+---+ 769 | | | | | 770 | f |op1|op2| m | 771 | | | | | 772 +---+---+---+---+ octet 773 | 1 | 1 | 1 | 1 | count 775 The first octet ('f') is the special function code, found in table 4.1. 776 The next two octets ('op1' and 'op2') are operands for the indicated 777 function. If not used, an operand must be set to zero. The last octet, 778 'm', is the enumerated value for a particular base layer encapsulation, 779 found in table 4.2. All four octets are encoded in network-byte-order. 781 5.1.1. Protocol Identifier Functions 783 The base layer identifier contains information about any special 784 functions to perform during collections of this protocol, as well as the 785 base layer encapsulation identifier. 787 Draft RMON Protocol Identifiers May 1996 789 The first three octets of the identifier contain the function code and 790 two optional operands. The fourth octet contains the particular base 791 layer encapsulation used in this protocol (fig. 2). 793 Table 4.1 Assigned Protocol Identifier Functions 794 ------------------------------------------------- 796 Function ID Param1 Param2 797 ---------------------------------------------------- 798 none 0 not used (0) not used (0) 799 wildcard 1 not used (0) not used (0) 801 5.1.1.1. Function 0: No-op 803 If the function ID field (1st octet) is equal to zero, the the 'op1' and 804 'op2' fields (2nd and 3rd octets) must also be equal to zero. This 805 special value indicates that no functions are applied to the protocol 806 identifier encoded in the remaining octets. The identifier represents a 807 normal protocol encapsulation. 809 5.1.1.2. Function 1: Protocol Wildcard Function 811 The wildcard function (function-ID = 1), is used to aggregate counters, 812 by using a single protocol value to indicate potentially many base layer 813 encapsulations of a particular network layer protocol. A 814 protocolDirEntry of this type will match any base-layer encapsulation of 815 the same protocol. 817 The 'op1' field (2nd octet) is not used and must be set to zero. 819 The 'op2' field (3rd octet) is not used and must be set to zero. 821 Each wildcard protocol identifier must be defined in terms of a 'base 822 encapsulation'. This should be as 'standard' as possible for 823 interoperability purposes. If an encapsulation over 'ether2' is 824 permitted, than this should be used as the base encapsulation. 826 The agent may also be requested to count some or all of the individual 827 encapsulations for the same protocols, in addition to wildcard counting. 828 Note that the RMON-2 MIB [RMON2] does not require that agents maintain 829 counters for multiple encapsulations of the same protocol. It is an 830 implementation-specific matter as to how an agent determines which 831 Draft RMON Protocol Identifiers May 1996 833 protocol combinations to allow in the protocolDirTable at any given 834 time. 836 5.2. Base Layer Protocol Identifiers 838 The base layer is mandatory, and defines the base encapsulation of the 839 packet and any special functions for this identifier. 841 There are no suggested protocolDirParameters bits for the base layer. 843 The suggested ProtocolDirDescr field for the base layer is given by the 844 corresponding "Name" field in the table 4.1 below. However, 845 implementations are only required to use the appropriate integer 846 identifier values. 848 For most base layer protocols, the protocolDirType field should contain 849 bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)' 850 attributes. However, the special 'wgAssigned' base layer should have no 851 parameter or attribute bits set. 853 By design, only 255 different base layer encapsulations are supported. 854 There are five base encapsulation values defined at this time. New base 855 encapsulations (e.g. for new media types) are expected to be added over 856 time. 858 Table 4.2 Base Layer Encoding Values 859 -------------------------------------- 861 Name ID 862 ------------------ 863 ether2 1 864 llc 2 865 snap 3 866 vsnap 4 867 wgAssigned 5 869 5.2.1. Ether2 Encapsulation 871 ether2 PROTOCOL-IDENTIFIER 872 PARAMETERS { } 873 ATTRIBUTES { 875 Draft RMON Protocol Identifiers May 1996 877 hasChildren(0), 878 addressRecognitionCapable(1) 879 } 880 DESCRIPTION 881 "DIX Ethernet, also called Ethernet-II." 882 CHILDREN 883 "The Ethernet-II type field is used to select child protocols. 884 This is a 16-bit field. Child protocols are deemed to start at 885 the first octet after this type field. 887 Children of this protocol are encoded as [ 0.0.0.1 ], the 888 protocol identifier for 'ether2' followed by [ 0.0.a.b ] where 889 'a' and 'b' are the network byte order encodings of the MSB and 890 LSB of the Ethernet-II type value. 892 For example, a protocolDirID-fragment value of: 893 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. 895 Children of are named as 'ether2' followed by the type field 896 value in hexadecimal. The above example would be declared as: 897 ether2 0x0800" 898 ADDRESS-FORMAT 899 "Ethernet addresses are 6 octets in network order." 900 DECODING 901 "Only type values greater than or equal to 1500 decimal indicate 902 Ethernet-II frames; lower values indicate 802.3 encapsulation 903 (see below)." 904 REFERENCE 905 "A Standard for the Transmission of IP Datagrams over Ethernet 906 Networks; RFC 894 [RFC894]. 908 The authoritative list of Ether Type values is identified by the 909 URL: 911 ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" 912 ::= { 1 } 914 5.2.2. LLC Encapsulation 916 llc PROTOCOL-IDENTIFIER 917 PARAMETERS { } 918 ATTRIBUTES { 919 hasChildren(0), 920 addressRecognitionCapable(1) 921 } 923 Draft RMON Protocol Identifiers May 1996 925 DESCRIPTION 926 "The LLC (802.2) protocol." 927 CHILDREN 928 "The LLC SSAP and DSAP (Source/Dest Service Access Points) are 929 used to select child protocols. Each of these is one octet long, 930 although the least significant bit is a control bit and should be 931 masked out in most situations. Typically SSAP and DSAP (once 932 masked) are the same for a given protocol - each end implicitly 933 knows whether it is the server or client in a client/server 934 protocol. This is only a convention, however, and it is possible 935 for them to be different. The SSAP is matched against child 936 protocols first. If none is found then the DSAP is matched 937 instead. The child protocol is deemed to start at the first 938 octet after the LLC control field(s). 940 Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol 941 identifier component for LLC followed by [ 0.0.0.a ] where 'a' is 942 the SAP value which maps to the child protocol. For example, a 943 protocolDirID-fragment value of: 944 0.0.0.2.0.0.0.240 946 defines NetBios over LLC. 948 Children are named as 'llc' followed by the SAP value in 949 hexadecimal. So the above example would have been named: 950 llc 0xf0" 951 ADDRESS-FORMAT 952 "The address consists of 6 octets of MAC address in network 953 order. Source routing bits should be stripped out of the address 954 if present." 955 DECODING 956 "Notice that LLC has a variable length protocol header; there are 957 always three octets (DSAP, SSAP, control). Depending on the 958 value of the control bits in the DSAP, SSAP and control fields 959 there may be an additional octet of control information. 961 LLC can be present on several different media. For 802.3 and 962 802.5 its presence is mandated (but see ether2 and raw802.3 963 encapsulations). For 802.5 there is no other link layer 964 protocol. 966 Notice also that the raw802.3 link layer protocol may take 967 precedence over this one in a protocol specific manner such that 968 it may not be possible to utilize all LSAP values if raw802.3 is 969 also present." 971 Draft RMON Protocol Identifiers May 1996 973 REFERENCE 974 "The authoritative list of LLC LSAP values is controlled by the 975 IEEE Registration Authority: 976 IEEE Registration Authority 977 c/o Iris Ringel 978 IEEE Standards Dept 979 445 Hoes Lane, P.O. Box 1331 980 Piscataway, NJ 08855-1331 981 Phone +1 908 562 3813 982 Fax: +1 908 562 1571" 983 ::= { 2 } 985 5.2.3. SNAP over LLC (OUI=000) Encapsulation 987 snap PROTOCOL-IDENTIFIER 988 PARAMETERS { } 989 ATTRIBUTES { 990 hasChildren(0), 991 addressRecognitionCapable(1) 992 } 993 DESCRIPTION 994 "The Sub-Network Access Protocol (SNAP) is layered on top of LLC 995 protocol, allowing Ethernet-II protocols to be run over a media 996 restricted to LLC." 997 CHILDREN 998 "Children of 'snap' are identified by Ethernet-II type values; 999 the SNAP PID (Protocol Identifier) field is used to select the 1000 appropriate child. The entire SNAP protocol header is consumed; 1001 the child protocol is assumed to start at the next octet after 1002 the PID. 1004 Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol 1005 identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' 1006 are the MSB and LSB of the Ethernet-II type value. For example, 1007 a protocolDirID-fragment value of: 1008 0.0.0.3.0.0.8.0 1010 defines the IP/SNAP protocol. 1012 Children of this protocol are named 'snap' followed by the 1013 Ethernet-II type value in hexadecimal. The above example would 1014 be named: 1016 snap 0x0800" 1017 ADDRESS-FORMAT 1019 Draft RMON Protocol Identifiers May 1996 1021 "The address format for SNAP is the same as that for LLC" 1022 DECODING 1023 "SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA 1024 and a single control octet will be present. There are then three 1025 octets of OUI and two octets of PID. For this encapsulation the 1026 OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)." 1027 REFERENCE 1028 "SNAP Identifier values are assigned by the IEEE Standards 1029 Office. The address is: 1030 IEEE Registration Authority 1031 c/o Iris Ringel 1032 IEEE Standards Dept 1033 445 Hoes Lane, P.O. Box 1331 1034 Piscataway, NJ 08855-1331 1035 Phone +1 908 562 3813 1036 Fax: +1 908 562 1571" 1037 ::= { 3 } 1039 5.2.4. SNAP over LLC (OUI != 000) Encapsulation 1041 vsnap PROTOCOL-IDENTIFIER 1042 PARAMETERS { } 1043 ATTRIBUTES { 1044 hasChildren(0), 1045 addressRecognitionCapable(1) 1046 } 1047 DESCRIPTION 1048 "This pseudo-protocol handles all SNAP packets which do not have 1049 a zero OUI. See 'snap' above for details of those that do." 1050 CHILDREN 1051 "Children of 'vsnap' are selected by the 3 octet OUI; the PID is 1052 not parsed; child protocols are deemed to start with the first 1053 octet of the SNAP PID field, and continue to the end of the 1054 packet. 1056 Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol 1057 identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where 1058 'a', 'b' and 'c' are the 3 octets of the OUI field in network 1059 byte order. This is in turn followed by the 16-bit EtherType 1060 value, where the 'd' and 'e' represent the MSB and LSB of the 1061 EtherType, respectively. 1063 For example, a protocolDirID-fragment value of: 1064 0.0.0.4.0.8.0.7.0.0.128.155 1066 Draft RMON Protocol Identifiers May 1996 1068 defines the Appletalk Phase 2 protocol over vsnap. 1070 Note that two protocolDirParameters octets must be present in 1071 protocolDirTable INDEX values for 'vsnap' protocols. The first 1072 protocolDirParameters octet defines the actual parameters. The 1073 second protocolDirParameters octet is not used and must be set to 1074 zero. 1076 Children are named as 'vsnap() ', where the 1077 '' field is represented as 3 octets in hexadecimal notation 1078 or the ASCII string associated with the OUI value. The 1079 field is represented by the 2 byte EtherType value in 1080 hexadecimal notation. So the above example would be named: 1082 'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'" 1083 ADDRESS-FORMAT 1084 "The LLC address format is inherited by 'vsnap'. See the 'llc' 1085 protocol identifier for more details." 1086 DECODING 1087 "Same as for 'snap' except the OUI is non-zero." 1088 REFERENCE 1089 "SNAP Identifier values are assigned by the IEEE Standards 1090 Office. The address is: 1091 IEEE Registration Authority 1092 c/o Iris Ringel 1093 IEEE Standards Dept 1094 445 Hoes Lane, P.O. Box 1331 1095 Piscataway, NJ 08855-1331 1096 Phone +1 908 562 3813 1097 Fax: +1 908 562 1571" 1098 ::= { 4 } 1100 5.2.5. Working Group Assigned Protocols 1102 wgAssigned PROTOCOL-IDENTIFIER 1103 PARAMETERS { } 1104 ATTRIBUTES { } 1105 DESCRIPTION 1106 "This branch contains protocols which do not conform easily to 1107 the hierarchical format utilized in the other link layer 1108 branches. Usually, such a protocol 'almost' conforms to a 1109 particular 'well-known' identifier format, but additional 1110 criteria are used (e.g. configuration-based), making protocol 1111 identification difficult or impossible by examination of 1112 appropriate network traffic. preventing the any 'well-known' 1114 Draft RMON Protocol Identifiers May 1996 1116 protocol-identifier macro from being used. 1118 Sometimes well-known protocols are simply remapped to a different 1119 port number by one or more venders (e.g. SNMP). These protocols 1120 can be identified with the 'user-extensibility' feature of the 1121 protocolDirTable, and do not need special working group 1122 assignments. 1124 A centrally located list of these enumerated protocols must be 1125 maintained by the RMON working group to insure interoperability. 1126 (See section 3.2 for details on the document update procedure.) 1127 Support for new link-layers will be added explicitly, and only 1128 protocols which cannot possibly be represented in a better way 1129 will be considered as 'wgEnumerated' protocols. 1131 Working group protocols are identified by the base-layer-selector 1132 value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the 1133 integer value corresponding to the particular WG protocol. 1135 Do not create children of this protocol unless you are sure that 1136 they cannot be handled by the more conventional link layers 1137 above." 1138 CHILDREN 1139 "Children of this protocol are identified by implementation- 1140 specific means, described (as best as possible) in the 'DECODING' 1141 clause within the protocol-variant-identifier macro for each 1142 enumerated protocol. 1144 For example, a protocolDirID-fragment value of: 1145 0.0.0.5.0.0.0.1 1147 defines the IPX protocol encapsulated directly in 802.3 1149 Children are named 'wgAssigned' followed by the name or numeric 1150 of the particular working group assigned protocol. The above 1151 example would be named: 1153 'wgAssigned 1' or 'wgAssigned ipxOverRaw8023'" 1155 DECODING 1156 "The 'wgAssigned' base layer is a pseudo-protocol and is not 1157 decoded." 1158 REFERENCE 1159 "Refer to individual PROTOCOL-IDENTIFIER macros for information 1160 on each child of the working group assigned protocol." 1162 Draft RMON Protocol Identifiers May 1996 1164 ::= { 5 } 1166 5.2.5.1. Working Group Assigned Protocol Identifiers 1168 The following protocol-variant-identifier macro declarations are used to 1169 identify the RMONMIB WG assigned protocols in a proprietary way, by 1170 simple enumeration. Note that an additional four-octet layer identifier 1171 may be used for some enumerations (as with the 'vsnap' base-layer 1172 identifier). Refer to the 'CHILDREN' clause in the protocol-identifier 1173 macro for a particular protocol to determine the number of octets in the 1174 'wgAssigned' layer-identifier. 1176 ipxOverRaw8023 PROTOCOL-IDENTIFIER 1177 VARIANT-OF "ipx" 1178 PARAMETERS { } 1179 ATTRIBUTES { } 1180 DESCRIPTION 1181 "This pseudo-protocol describes an encapsulation of IPX over 1182 802.3, without a type field. 1184 Refer to the macro for IPX for additional information about this 1185 protocol." 1186 DECODING 1187 "Whenever the 802.3 header indicates LLC a set of protocol 1188 specific tests needs to be applied to determine whether this is a 1189 'raw8023' packet or a true 802.2 packet. The nature of these 1190 tests depends on the active child protocols for 'raw8023' and is 1191 beyond the scope of this document." 1192 ::= { wgAssigned 1 } 1194 5.3. L3: Children of Base Protocol Identifiers 1196 Network layer protocol identifier macros contain additional information 1197 about the network layer, and is found immediately following a base 1198 layer-identifier in a protocol identifier. 1200 The ProtocolDirParameters supported at the network layer are 1201 'countsFragments(0)', and 'tracksSessions(1). An agent may choose to 1202 implement a subset of these parameters. 1204 The protocol-name should be used for the ProtocolDirDescr field. The 1205 ProtocolDirType ATTRIBUTES used at the network layer are 1206 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose 1207 to implement a subset of these attributes for each protocol, and 1208 Draft RMON Protocol Identifiers May 1996 1210 therefore limit which tables the indicated protocol can be present (e.g. 1211 protocol distribution, host, and matrix tables).. 1213 The following protocol-identifier macro declarations are given for 1214 example purposes only. They are not intended to constitute an exhaustive 1215 list or an authoritative source for any of the protocol information 1216 given. However, any protocol that can encapsulate other protocols must 1217 be documented here in order to encode the children identifiers into 1218 protocolDirID strings. Leaf protocols should be documented as well, but 1219 an implementation can identify a leaf protocol even if it isn't listed 1220 here (as long as the parent is documented). 1222 5.3.1. IP 1224 ip PROTOCOL-IDENTIFIER 1225 PARAMETERS { 1226 countsFragments(0) -- This parameter applies to all child 1227 -- protocols. 1228 } 1229 ATTRIBUTES { 1230 hasChildren(0), 1231 addressRecognitionCapable(1) 1232 } 1233 DESCRIPTION 1234 "The protocol identifiers for the Internet Protocol (IP). Note 1235 that IP may be encapsulated within itself, so more than one of 1236 the following identifiers may be present in a particular 1237 protocolDirID string." 1238 CHILDREN 1239 "Children of 'ip' are selected by the value in the Protocol field 1240 (one octet), as defined in the PROTOCOL NUMBERS table within the 1241 Assigned Numbers Document. 1243 The value of the Protocol field is encoded in an octet string as 1244 [ 0.0.0.a ], where 'a' is the protocol field . 1246 Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a' 1247 where 'a' is the protocol field value. For example, a 1248 protocolDirID-fragment value of: 1249 0.0.0.1.0.0.8.0.0.0.0.1 1251 defines an encapsulation of ICMP (ether2.ip.icmp)" 1252 ADDRESS-FORMAT 1253 "4 octets of the IP address, in network byte order. Each ip 1255 Draft RMON Protocol Identifiers May 1996 1257 packet contains two addresses, the source address and the 1258 destination address." 1259 DECODING 1260 "Note: ether2/ip/ipip4/udp is a different protocolDirID than 1261 ether2/ip/udp, as identified in the protocolDirTable. As such, 1262 two different local protocol index values will be assigned by the 1263 agent. E.g. (full INDEX values shown): 1264 ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0 1265 ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 " 1266 REFERENCE 1267 "RFC 791 [RFC791] defines the Internet Protocol; The following 1268 URL defines the authoritative repository for the PROTOCOL NUMBERS 1269 Table: 1271 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers" 1272 ::= { 1273 ether2 0x0800, 1274 llc 0x06, 1275 snap 0x0800, 1276 ip 4, 1277 ip 94 1278 } 1280 5.3.2. IPX 1282 ipx PROTOCOL-IDENTIFIER 1283 PARAMETERS { } 1284 ATTRIBUTES { 1285 hasChildren(0), 1286 addressRecognitionCapable(1) 1287 } 1288 DESCRIPTION 1289 "Novell IPX" 1290 CHILDREN 1291 "Children of IPX are defined by the 16 bit value of the 1292 Destination Socket field. The value is encoded into an octet 1293 string as [ 0.0.a.b ], where 'a' and 'b' are the network byte 1294 order encodings of the MSB and LSB of the destination socket 1295 field." 1296 ADDRESS-FORMAT 1297 "4 bytes of Network number followed by the 6 bytes Host address 1298 each in network byte order". 1299 REFERENCE 1301 Draft RMON Protocol Identifiers May 1996 1303 "The IPX protocol is defined by the Novell Corporation 1305 A complete description of IPX may be secured at the following 1306 address: 1307 Novell, Inc. 1308 122 East 1700 South 1309 P. O. Box 5900 1310 Provo, Utah 84601 USA 1311 800 526 5463 1312 Novell Part # 883-000780-001" 1313 ::= { 1314 ether2 0x8137, -- 0.0.129.55 1315 llc 0xe0e003, -- 0.224.224.3 1316 snap 0x8137, -- 0.0.129.55 1317 wgAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023) 1318 } 1320 5.3.3. ARP 1322 arp PROTOCOL-IDENTIFIER 1323 PARAMETERS { } 1324 ATTRIBUTES { } 1325 DESCRIPTION 1326 "An Address Resolution Protocol message (request or response). 1327 This protocol does not include Reverse ARP (RARP) packets, which 1328 are counted separately." 1329 REFERENCE 1330 "RFC 826 [RFC826] defines the Address Resolution Protocol." 1331 ::= { 1332 ether2 0x806, -- [ 0.0.8.6 ] 1333 snap 0x806 1334 } 1336 5.3.4. IDP 1338 idp PROTOCOL-IDENTIFIER 1339 PARAMETERS { } 1340 ATTRIBUTES { 1341 hasChildren(0), 1342 addressRecognitionCapable(1) 1343 } 1344 DESCRIPTION 1345 "Xerox IDP" 1346 CHILDREN 1348 Draft RMON Protocol Identifiers May 1996 1350 "Children of IDP are defined by the 8 bit value of the Packet 1351 type field. The value is encoded into an octet string as [ 1352 0.0.0.a ], where 'a' is the value of the packet type field in 1353 network byte order." 1354 ADDRESS-FORMAT 1355 "4 bytes of Network number followed by the 6 bytes Host address 1356 each in network byte order". 1357 REFERENCE 1358 "Xerox Corporation, Document XNSS 028112, 1981" 1359 ::= { 1360 ether2 0x600, -- [ 0.0.6.0 ] 1361 snap 0x600 1362 } 1364 5.3.5. Appletalk ARP 1366 atalkarp PROTOCOL-IDENTIFIER 1367 PARAMETERS { } 1368 ATTRIBUTES { } 1369 DESCRIPTION 1370 "Appletalk Address Resolution Protocol." 1371 REFERENCE 1372 "AppleTalk Phase 2 Protocol Specification, document ADPA 1373 #C0144LL/A." 1374 ::= { 1375 ether2 0x80f3, -- [ 0.0.128.243 ] 1376 vsnap(0x080007) 0x80f3 1377 } 1379 5.3.6. Appletalk 1381 atalk PROTOCOL-IDENTIFIER 1382 PARAMETERS { } 1383 ATTRIBUTES { 1384 hasChildren(0), 1385 addressRecognitionCapable(1) 1386 } 1387 DESCRIPTION 1388 "AppleTalk Protocol." 1389 CHILDREN 1390 "Children of ATALK are defined by the 8 bit value of the DDP type 1391 field. The value is encoded into an octet string as [ 0.0.0.a ], 1392 where 'a' is the value of the DDP type field in network byte 1393 order." 1395 Draft RMON Protocol Identifiers May 1996 1397 ADDRESS-FORMAT 1398 "2 bytes of Network number followed by 1 byte of node id each in 1399 network byte order". 1400 REFERENCE 1401 "AppleTalk Phase 2 Protocol Specification, document ADPA 1402 #C0144LL/A." 1403 ::= { 1404 ether2 0x809b, -- [ 0.0.128.155 ] 1405 vsnap(0x080007) 0x809b 1406 } 1408 5.4. L4: Children of L3 Protocols 1410 5.4.1. ICMP 1412 icmp PROTOCOL-IDENTIFIER 1413 PARAMETERS { } 1414 ATTRIBUTES { } 1415 DESCRIPTION 1416 "Internet Message Control Protocol." 1417 REFERENCE 1418 "RFC 792 [RFC792] defines the Internet Control Message Protocol." 1419 ::= { ip 1 } 1421 5.4.2. TCP 1423 tcp PROTOCOL-IDENTIFIER 1424 PARAMETERS { } 1425 ATTRIBUTES { 1426 hasChildren(0) 1427 } 1428 DESCRIPTION 1429 "Transmission Control Protocol." 1430 CHILDREN 1431 "Children of TCP are identified by the 16 bit Destination Port 1432 value as specified in RFC 793. They are encoded as [ 0.0.a.b], 1433 where 'a' is the MSB and 'b' is the LSB of the Destination Port 1434 value. Both bytes are encoded in network byte order. For 1435 example, a protocolDirId-fragment of: 1436 0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23 1438 identifies an encapsulation of the telnet protocol 1439 (ether2.ip.tcp.telnet)" 1440 REFERENCE 1442 Draft RMON Protocol Identifiers May 1996 1444 "RFC 793 [RFC793] defines the Trasmission Control Protocol. 1446 The following URL defines the authoritative repository for 1447 reserved and registered TCP port values: 1449 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 1450 ::= { ip 6 } 1452 5.4.3. UDP 1454 udp PROTOCOL-IDENTIFIER 1455 PARAMETERS { } 1456 ATTRIBUTES { 1457 hasChildren(0) 1458 } 1459 DESCRIPTION 1460 "User Datagram Protocol." 1461 CHILDREN 1462 "Children of UDP are identified by the 16 bit Destination Port 1463 value as specified in RFC 768. They are encoded as [ 0.0.a.b ], 1464 where 'a' is the MSB and 'b' is the LSB of the Destination Port 1465 value. Both bytes are encoded in network byte order. For 1466 example, a protocolDirId-fragment of: 1467 0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161 1469 identifies an encapsulation of SNMP (ether2.ip.udp.snmp)" 1470 REFERENCE 1471 "RFC 768 [RFC768] defines the User Datagram Protocol. 1473 The following URL defines the authoritative repository for 1474 reserved and registered UDP port values: 1476 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers" 1477 ::= { ip 17 } 1479 5.5. L5: Applicataion Layer Protocols 1481 5.5.1. FTP 1483 5.5.1.1. FTP-DATA 1484 ftp-data PROTOCOL-IDENTIFIER 1485 PARAMETERS { } 1486 ATTRIBUTES { } 1487 DESCRIPTION 1488 "The File Transfer Protocol Data Port; the FTP Server process 1490 Draft RMON Protocol Identifiers May 1996 1492 default data-connection port. " 1493 REFERENCE 1494 "RFC 959 [RFC959] defines the File Transfer Protocol. Refer to 1495 section 3.2 of [RFC959] for details on FTP data connections." 1496 ::= { tcp 20 } 1498 5.5.1.2. FTP Control 1500 ftp PROTOCOL-IDENTIFIER 1501 PARAMETERS { } 1502 ATTRIBUTES { } 1503 DESCRIPTION 1504 "The File Transfer Protocol Control Port; An FTP client initiates 1505 an FTP control connection by sending FTP commands from user port 1506 (U) to this port." 1507 REFERENCE 1508 "RFC 959 [RFC959] defines the File Transfer Protocol." 1509 ::= { tcp 21 } 1511 5.5.2. Telnet 1513 telnet PROTOCOL-IDENTIFIER 1514 PARAMETERS { } 1515 ATTRIBUTES { } 1516 DESCRIPTION 1517 "The Telnet Protocol; The purpose of the TELNET Protocol is to 1518 provide a fairly general, bi-directional, eight-bit byte oriented 1519 communications facility. Its primary goal is to allow a standard 1520 method of interfacing terminal devices and terminal-oriented 1521 processes to each other. " 1522 REFERENCE 1523 "RFC 854 [RFC854] defines the basic Telnet Protocol." 1524 ::= { tcp 23 } 1526 5.5.3. SMTP 1528 smtp PROTOCOL-IDENTIFIER 1529 PARAMETERS { } 1530 ATTRIBUTES { } 1531 DESCRIPTION 1532 "The Simple Mail Transfer Protocol; SMTP control and data 1533 messages are sent on this port." 1534 REFERENCE 1535 "RFC 821 [RFC821] defines the basic Simple Mail Transfer 1536 Protocol." 1538 Draft RMON Protocol Identifiers May 1996 1540 ::= { tcp 25 } 1542 5.5.4. DNS 1544 domain PROTOCOL-IDENTIFIER 1545 PARAMETERS { } 1546 ATTRIBUTES { } 1547 DESCRIPTION 1548 "Domain Name Service Protocol; DNS may be transported by either 1549 UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS 1550 requests restricted to 512 bytes in length may be sent to this 1552 port." 1553 REFERENCE 1554 "RFC 1035 [RFC1035] defines the Bootstrap Protocol." 1555 ::= { udp 53, 1556 tcp 53 } 1558 5.5.5. BOOTP 1560 5.5.5.1. Bootstrap Server Protocol 1562 bootps PROTOCOL-IDENTIFIER 1563 PARAMETERS { } 1564 ATTRIBUTES { } 1565 DESCRIPTION 1566 "Bootstrap Protocol Server Protocol; BOOTP Clients send requests 1567 (usually broadcast) to the bootps port." 1568 REFERENCE 1569 "RFC 951 [RFC951] defines the Bootstrap Protocol." 1570 ::= { udp 67 } 1572 5.5.5.2. Bootstrap Client Protocol 1574 bootpc PROTOCOL-IDENTIFIER 1575 PARAMETERS { } 1576 ATTRIBUTES { } 1577 DESCRIPTION 1578 "Bootstrap Protocol Client Protocol; BOOTP Server replies are 1579 sent to the BOOTP Client using this destination port." 1580 REFERENCE 1581 "RFC 951 [RFC951] defines the Bootstrap Protocol." 1582 ::= { udp 68 } 1584 Draft RMON Protocol Identifiers May 1996 1586 5.5.6. TFTP 1588 tftp PROTOCOL-IDENTIFIER 1589 PARAMETERS { 1590 tracksSessions(1) 1591 } 1592 ATTRIBUTES { } 1593 DESCRIPTION 1594 "Trivial File Transfer Protocol; Only the first packet of each 1595 TFTP transaction will be sent to port 69. If the tracksSessions 1596 attribute is set, then packets for each TFTP transaction will be 1597 attributed to tftp, instead of the unregistered port numbers that 1598 will be encoded in subsequent packets." 1599 REFERENCE 1600 "RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC 1601 1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783] 1602 defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines 1603 TFTP Timeout Interval and Transfer Size Options." 1605 ::= { udp 69 } 1607 5.5.7. HTTP 1609 www-http PROTOCOL-IDENTIFIER 1610 PARAMETERS { } 1611 ATTRIBUTES { } 1612 DESCRIPTION 1613 "Hypertext Transfer Protocol; " 1614 REFERENCE 1615 "RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol 1616 (HTTP/1.0)." 1617 ::= { tcp 80 } 1619 5.5.8. POP3 1621 pop3 PROTOCOL-IDENTIFIER 1622 PARAMETERS { } 1623 ATTRIBUTES { } 1624 DESCRIPTION 1625 "Post Office Protocol -- Version 3. Clients establish connections 1626 with POP3 servers by using this destination port number." 1627 REFERENCE 1628 "RFC 1725 [RFC1725] defines Version 3 of the Post Office 1629 Protocol." 1630 ::= { tcp 110 } 1632 Draft RMON Protocol Identifiers May 1996 1634 5.5.9. SUNRPC 1636 sunrpc PROTOCOL-IDENTIFIER 1637 PARAMETERS { } 1638 ATTRIBUTES { 1639 hasChildren(0) -- port mapper function numbers 1640 } 1641 DESCRIPTION 1642 "SUN Remote Procedure Call Protocol. Port mapper function 1643 requests are sent to this destination port." 1644 CHILDREN 1645 Specific RPC functions are represented as children of the sunrpc 1646 protocol. Each 'RPC function protocol' is identified by its 1647 function number assignment. RPC function number assignments are 1648 defined by different naming authorities, depending of the 1649 function identifier value. 1650 From [RFC1831]: 1652 Program numbers are given out in groups of hexadecimal 20000000 1653 (decimal 536870912) according to the following chart: 1655 0 - 1fffffff defined by rpc@sun.com 1656 20000000 - 3fffffff defined by user 1657 40000000 - 5fffffff transient 1658 60000000 - 7fffffff reserved 1659 80000000 - 9fffffff reserved 1660 a0000000 - bfffffff reserved 1661 c0000000 - dfffffff reserved 1662 e0000000 - ffffffff reserved 1664 Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol 1665 identifier component for 'sunrpc', followed by [ a.b.c.d ], where 1666 a.b.c.d is the 32 bit binary RPC program number encoded in 1667 network byte order. For example, a protocolDirID-fragment value 1668 of: 1669 0.0.0.111.0.1.134.163 1671 defines the NFS function (and protocol). 1673 Children are named as 'sunrpc' followed by the RPC function 1674 number in base 10 format. For example, NFS would be named: 1675 'sunrpc 100003'. 1676 REFERENCE 1677 "RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol 1678 Version 2. The authoritative list of RPC Functions is identified 1680 Draft RMON Protocol Identifiers May 1996 1682 by the URL: 1683 ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers" 1684 ::= { udp 111 } 1686 5.5.10. NFS 1688 nfs PROTOCOL-IDENTIFIER 1689 PARAMETERS { 1690 countsFragments(0) 1691 } 1692 ATTRIBUTES { } 1693 DESCRIPTION 1694 "Sun Network File System (NFS);" 1695 DECODING 1696 "The first packet in an NFS transaction is sent to the port- 1697 mapper, and therefore decoded statically by monitoring RFC 1698 portmap requests [RFC1831]. Any subsequent NFS fragments must be 1699 decoded and correctly identified by 'remembering' the port 1700 assignments used in each RPC function call (as identified 1701 according to the procedures in the RPC Specification Version 2 1702 [RFC1831]). 1704 The 'countsFragments(0)' PARAMETER bit is used to indicate 1705 whether the probe can (and should) monitor portmapper activity to 1706 correctly attribute all NFS packets." 1707 REFERENCE 1708 "The NFS Version 3 Protocol Specification is defined in RFC 1813 1709 [RFC1813]." 1710 ::= { 1711 sunrpc 100003 -- [0.1.134.163] 1712 } 1714 5.5.11. SNMP 1716 5.5.11.1. SNMP Request/Response 1717 snmp PROTOCOL-IDENTIFIER 1718 PARAMETERS { } 1719 ATTRIBUTES { } 1720 DESCRIPTION 1721 "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2 1722 protocol versions. Does not include SNMP trap packets." 1723 REFERENCE 1724 "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP 1725 protocol is defined in RFC 1905 [RFC1905]. Transport mappings 1726 are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) 1728 Draft RMON Protocol Identifiers May 1996 1730 [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." 1731 ::= { 1732 udp 161, 1733 ipx 0x900f, -- [ 0.0.144.15 ] 1734 atalk 8 1735 } 1737 5.5.11.2. SNMP Trap 1739 snmptrap PROTOCOL-IDENTIFIER 1740 PARAMETERS { } 1741 ATTRIBUTES { } 1742 DESCRIPTION 1743 "Simple Network Management Protocol Trap Port." 1744 REFERENCE 1745 "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP 1746 protocol is defined in RFC 1905 [RFC1905]. Transport mappings 1747 are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX) 1748 [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]." 1749 ::= { 1750 udp 162, 1751 ipx 0x9010, 1752 atalk 9 1753 } 1755 6. Acknowledgements 1757 This document was produced by the IETF RMONMIB Working Group. 1759 The authors wish to thank the following people for their contributions 1760 to this document: 1762 Anil Singhal 1763 Frontier Software Development, Inc. 1765 Jeanne Haney 1766 Bay Networks 1768 Dan Hansen 1769 Network General Corp. 1771 Draft RMON Protocol Identifiers May 1996 1773 7. References 1775 [RFC768] 1776 Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1777 USC/Information Sciences Institute, August 1980. 1779 [RFC791] 1780 Postel, J., ed., "Internet Protocol - DARPA Internet Program 1781 Protocol Specification", STD 5, RFC 791, USC/Information Sciences 1782 Institute, September 1981. 1784 [RFC792] 1785 Postel, J., "Internet Control Message Protocol - DARPA Internet 1786 Program Protocol Specification", STD 5, RFC 792, USC/Information 1787 Sciences Institute, September 1981. 1789 [RFC793] 1790 Postel, J., "Transmission Control Protocol - DARPA Internet Program 1791 Protocol Specification", STD 5, RFC 793, USC/Information Sciences 1792 Institute, September 1981. 1794 [RFC821] 1795 Postel, J., "Simple Mail Transfer Protocol", RFC 821, 1796 USC/Information Sciences Institute, August 1982. 1798 [RFC826] 1799 Plummer, D., "An Ethernet Address Resolution Protocol or 1800 "Converting Network Protocol Addresses to 48-bit Ethernet Addresses 1801 for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS, 1802 November 1982. 1804 [RFC854] 1805 Postel, J. and Reynolds, J., "Telnet Protocol Specification", RFC 1806 854, ISI, May 1983. 1808 [RFC894] 1809 C.OHornig, "A Standard for the Transmission of IP Datagrams over 1810 Ethernet Networks", RFC 894, Symbolics, April 1984. 1812 [RFC951] 1813 Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951, 1814 Stanford and SUN Microsytems, September 1985. 1816 [RFC959] 1817 Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959, 1819 Draft RMON Protocol Identifiers May 1996 1821 USC/Information Sciences Institute, October 1985. 1823 [RFC1035] 1824 Mockapetris, P., "Domain Names - Implementation and Specification", 1825 STD 13, RFC 1035, USC/Information Sciences Institute, November 1826 1987. 1828 [RFC1157] 1829 Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1830 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1831 International, MIT Laboratory for Computer Science, May 1990. 1833 [RFC1213] 1834 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1835 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1836 RFC 1213, Hughes LAN Systems, Performance Systems International, 1837 March 1991. 1839 [RFC1350] 1840 Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July 1841 1992. 1843 [RFC1419] 1844 Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, 1845 Novell, Inc., Apple Computer, Inc., March 1993. 1847 [RFC1420] 1848 Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993. 1850 [RFC1700] 1851 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1852 USC/Information Sciences Institute, October 1994. 1854 [RFC1725] 1855 Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC 1856 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. 1858 [RFC1757] 1859 S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie 1860 Mellon University, February 1995. 1862 [RFC1782] 1863 Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782, 1864 Xylogics, Inc., Hewlett Packard Co., March 1995. 1866 Draft RMON Protocol Identifiers May 1996 1868 [RFC1783] 1869 Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783, 1870 Xylogics, Inc., Hewlett Packard Co., March 1995. 1872 [RFC1784] 1873 Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size 1874 Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March 1875 1995. 1877 [RFC1800] 1878 Postel, J., Editor, "Internet Official Protocol Standards", STD 1, 1879 RFC 1800, IAB, July 1995. 1881 [RFC1831] 1882 Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC 1883 1831, Sun Microsystems, Inc., August 1995. 1885 [RFC1902] 1886 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1887 S. Waldbusser, "Structure of Management Information for version 2 1888 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1889 January 1996. 1891 [RFC1903] 1892 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1893 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1894 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1896 [RFC1904] 1897 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1898 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1899 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1901 [RFC1905] 1902 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1903 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1904 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1906 [RFC1906] 1907 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1908 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 1909 Management Protocol (SNMPv2)", RFC 1906, January 1996. 1911 [RFC1945] 1912 Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol -- 1914 Draft RMON Protocol Identifiers May 1996 1916 HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995. 1918 [RMON2] 1919 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft- 1920 ietf-rmonmib-rmon2-03.txt, International Network Services, January 1921 1996. 1923 Draft RMON Protocol Identifiers May 1996 1925 8. Security Considerations 1927 Security issues are not discussed in this memo. 1929 9. Authors' Addresses 1931 Andy Bierman 1932 Cisco Systems, Inc. 1933 170 West Tasman Drive 1934 San Jose, CA 95134 1935 Phone: 408-527-3711 1936 Email: abierman@cisco.com 1938 Robin Iddon 1939 3Com/AXON 1940 40/50 Blackfrias Street 1941 Edinburgh, UK 1942 Phone: +44 131.558.3888 1943 Email: robini@axon.com 1945 Draft RMON Protocol Identifiers May 1996 1947 Table of Contents 1949 1 Introduction .................................................... 2 1950 2 The SNMP Network Management Framework ........................... 3 1951 2.1 Object Definitions ............................................ 3 1952 3 Overview ........................................................ 4 1953 3.1 Terms ......................................................... 4 1954 3.2 Relationship to the Remote Network Monitoring MIB ............. 6 1955 3.3 Relationship to the Other MIBs ................................ 7 1956 4 Protocol Identifier Encoding .................................... 8 1957 4.1 ProtocolDirTable INDEX Format Examples ........................ 11 1958 4.2 Protocol Identifier Macro Format .............................. 11 1959 4.2.1 Mapping of the Protocol Name ................................ 14 1960 4.2.2 Mapping of the VARIANT-OF Clause ............................ 14 1961 4.2.3 Mapping of the PARAMETERS Clause ............................ 15 1962 4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 16 1963 4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 16 1964 4.2.4 Mapping of the ATTRIBUTES Clause ............................ 17 1965 4.2.5 Mapping of the DESCRIPTION Clause ........................... 18 1966 4.2.6 Mapping of the CHILDREN Clause .............................. 18 1967 4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 19 1968 4.2.8 Mapping of the DECODING Clause .............................. 19 1969 4.2.9 Mapping of the REFERENCE Clause ............................. 19 1970 4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 20 1971 5 Protocol Identifier Macros ...................................... 21 1972 5.1 Base Identifier Encoding ...................................... 21 1973 5.1.1 Protocol Identifier Functions ............................... 21 1974 5.1.1.1 Function 0: No-op ......................................... 22 1975 5.1.1.2 Function 1: Protocol Wildcard Function .................... 22 1976 5.2 Base Layer Protocol Identifiers ............................... 23 1977 5.2.1 Ether2 Encapsulation ........................................ 23 1978 5.2.2 LLC Encapsulation ........................................... 24 1979 5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 26 1980 5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 27 1981 5.2.5 Working Group Assigned Protocols ............................ 28 1982 5.2.5.1 Working Group Assigned Protocol Identifiers ............... 30 1983 5.3 L3: Children of Base Protocol Identifiers ..................... 30 1984 5.3.1 IP .......................................................... 31 1985 5.3.2 IPX ......................................................... 32 1986 5.3.3 ARP ......................................................... 33 1987 5.3.4 IDP ......................................................... 33 1988 5.3.5 Appletalk ARP ............................................... 34 1989 5.3.6 Appletalk ................................................... 34 1990 5.4 L4: Children of L3 Protocols .................................. 35 1991 Draft RMON Protocol Identifiers May 1996 1993 5.4.1 ICMP ........................................................ 35 1994 5.4.2 TCP ......................................................... 35 1995 5.4.3 UDP ......................................................... 36 1996 5.5 L5: Applicataion Layer Protocols .............................. 36 1997 5.5.1 FTP ......................................................... 36 1998 5.5.1.1 FTP-DATA .................................................. 36 1999 5.5.1.2 FTP Control ............................................... 37 2000 5.5.2 Telnet ...................................................... 37 2001 5.5.3 SMTP ........................................................ 37 2002 5.5.4 DNS ......................................................... 38 2003 5.5.5 BOOTP ....................................................... 38 2004 5.5.5.1 Bootstrap Server Protocol ................................. 38 2005 5.5.5.2 Bootstrap Client Protocol ................................. 38 2006 5.5.6 TFTP ........................................................ 39 2007 5.5.7 HTTP ........................................................ 39 2008 5.5.8 POP3 ........................................................ 39 2009 5.5.9 SUNRPC ...................................................... 40 2010 5.5.10 NFS ........................................................ 41 2011 5.5.11 SNMP ....................................................... 41 2012 5.5.11.1 SNMP Request/Response .................................... 41 2013 5.5.11.2 SNMP Trap ................................................ 42 2014 6 Acknowledgements ................................................ 42 2015 7 References ...................................................... 43 2016 8 Security Considerations ......................................... 47 2017 9 Authors' Addresses .............................................. 47