idnits 2.17.1 draft-ietf-rmonmib-rmonprot-ref-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 2) being 111 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 10 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2074], [RFC2021]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 793 has weird spacing: '...agments high...' == Line 797 has weird spacing: '...essions cor...' == Line 1082 has weird spacing: '...set for the '...' == Line 1408 has weird spacing: '...section defin...' == Line 1575 has weird spacing: '...imed to perta...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Protocol-identifier parsing starts with the base layer identifier, which MUST be present, and continues for one or more upper layer identifiers, until all OCTETs of the protocolDirID have been used. Layers MAY NOT be skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can not exist. -- 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 (25 June 1999) is 9065 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 section? 'RFC2026' on line 17 looks like a reference -- Missing reference section? 'RFC2021' on line 1713 looks like a reference -- Missing reference section? 'RFC2074' on line 1717 looks like a reference -- Missing reference section? 'RFC2571' on line 1763 looks like a reference -- Missing reference section? 'RFC1155' on line 1645 looks like a reference -- Missing reference section? 'RFC1212' on line 1656 looks like a reference -- Missing reference section? 'RFC1215' on line 1660 looks like a reference -- Missing reference section? 'RFC2578' on line 1791 looks like a reference -- Missing reference section? 'RFC2579' on line 1798 looks like a reference -- Missing reference section? 'RFC2580' on line 1804 looks like a reference -- Missing reference section? 'RFC1157' on line 1650 looks like a reference -- Missing reference section? 'RFC1901' on line 1672 looks like a reference -- Missing reference section? 'RFC1906' on line 1706 looks like a reference -- Missing reference section? 'RFC2572' on line 1769 looks like a reference -- Missing reference section? 'RFC2574' on line 1780 looks like a reference -- Missing reference section? 'RFC1905' on line 1699 looks like a reference -- Missing reference section? 'RFC2573' on line 1775 looks like a reference -- Missing reference section? 'RFC2575' on line 1785 looks like a reference -- Missing reference section? 'RFC2570' on line 1757 looks like a reference -- Missing reference section? 'RFC2119' on line 1721 looks like a reference -- Missing reference section? 'RFC1902' on line 1678 looks like a reference -- Missing reference section? 'RFC1483' on line 1664 looks like a reference -- Missing reference section? 'RFC2233' on line 1725 looks like a reference -- Missing reference section? 'RFC1700' on line 1668 looks like a reference -- Missing reference section? 'IEEE802.1Q' on line 1639 looks like a reference -- Missing reference section? 'IEEE802.1D-1998' on line 1631 looks like a reference -- Missing reference section? 'RFC1903' on line 1685 looks like a reference -- Missing reference section? 'RFC1904' on line 1692 looks like a reference -- Missing reference section? 'RFC2271' on line 1729 looks like a reference -- Missing reference section? 'RFC2272' on line 1735 looks like a reference -- Missing reference section? 'RFC2273' on line 1741 looks like a reference -- Missing reference section? 'RFC2274' on line 1746 looks like a reference -- Missing reference section? 'RFC2275' on line 1751 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 36 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RMONMIB Working Group Andy Bierman 2 Internet Draft Cisco Systems, Inc. 3 Chris Bucci 4 Cisco Systems, Inc. 5 Robin Iddon 6 3Com, Inc. 7 25 June 1999 9 Remote Network Monitoring MIB Protocol Identifier Reference 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026 [RFC2026]. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this document is unlimited. Please send comments to the 34 RMONMIB Working Group, . 36 1. Copyright Notice 38 Copyright (C) The Internet Society (1998). All Rights Reserved. 40 2. Abstract 42 This memo defines a notation describing protocol layers in a protocol 43 encapsulation, specifically for use in encoding INDEX values for the 44 protocolDirTable, found in the RMON-2 MIB [RFC2021]. The definitions 45 for the standard protocol directory base layer identifiers are also 46 included. 48 The first version of the RMON Protocol Identifiers Document [RFC2074] 49 has been split into a standards-track Reference portion (this document), 50 and an Informational document. The RMON Protocol Identifier Macros 51 document [RMONPROT_MAC] now contains the non-normative portion of that 52 specification. 54 3. Table of Contents 56 1 Copyright Notice ................................................ 1 57 2 Abstract ........................................................ 2 58 3 Table of Contents ............................................... 3 59 4 The SNMP Network Management Framework ........................... 4 60 5 Overview ........................................................ 5 61 5.1 Terms ......................................................... 5 62 5.2 Relationship to the Remote Network Monitoring MIB ............. 8 63 5.3 Relationship to the RMON Protocol Identifier Macros Document 64 .............................................................. 8 65 5.4 Relationship to the ATM-RMON MIB .............................. 9 66 5.4.1 Port Aggregation ............................................ 9 67 5.4.2 Encapsulation Mappings ...................................... 9 68 5.4.3 Counting ATM Traffic in RMON-2 Collections .................. 10 69 5.5 Relationship to Other MIBs .................................... 10 70 6 Protocol Identifier Encoding .................................... 10 71 6.1 ProtocolDirTable INDEX Format Examples ........................ 13 72 6.2 Protocol Identifier Macro Format .............................. 14 73 6.2.1 Lexical Conventions ......................................... 14 74 6.2.2 Notation for Syntax Descriptions ............................ 14 75 6.2.3 Grammar for the PI Language ................................. 15 76 6.2.4 Mapping of the Protocol Name ................................ 17 77 6.2.5 Mapping of the VARIANT-OF Clause ............................ 18 78 6.2.6 Mapping of the PARAMETERS Clause ............................ 19 79 6.2.6.1 Mapping of the 'countsFragments(0)' BIT ................... 20 80 6.2.6.2 Mapping of the 'tracksSessions(1)' BIT .................... 20 81 6.2.7 Mapping of the ATTRIBUTES Clause ............................ 20 82 6.2.8 Mapping of the DESCRIPTION Clause ........................... 21 83 6.2.9 Mapping of the CHILDREN Clause .............................. 21 84 6.2.10 Mapping of the ADDRESS-FORMAT Clause ....................... 22 85 6.2.11 Mapping of the DECODING Clause ............................. 22 86 6.2.12 Mapping of the REFERENCE Clause ............................ 22 87 6.3 Evaluating an Index of the ProtocolDirectoryTable ............ 23 88 7 Base Layer Protocol Identifier Macros ........................... 24 89 7.1 Base Identifier Encoding ...................................... 24 90 7.1.1 Protocol Identifier Functions ............................... 25 91 7.1.1.1 Function 0: None .......................................... 25 92 7.1.1.2 Function 1: Protocol Wildcard Function .................... 26 93 7.2 Base Layer Protocol Identifiers ............................... 26 94 7.3 Encapsulation Layers .......................................... 34 95 7.3.1 IEEE 802.1Q ................................................. 34 96 8 Intellectual Property ........................................... 37 97 9 Acknowledgements ................................................ 38 98 10 References ..................................................... 39 99 11 IANA Considerations ............................................ 43 100 12 Security Considerations ........................................ 43 101 13 Authors' Addresses ............................................. 43 102 14 Full Copyright Statement ....................................... 45 104 4. The SNMP Network Management Framework 106 The SNMP Management Framework presently consists of five major 107 components: 109 o An overall architecture, described in RFC 2571 [RFC2571]. 111 o Mechanisms for describing and naming objects and events for the 112 purpose of management. The first version of this Structure of 113 Management Information (SMI) is called SMIv1 and described in 114 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 115 The second version, called SMIv2, is described in RFC 2578 116 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 118 o Message protocols for transferring management information. The 119 first version of the SNMP message protocol is called SNMPv1 and 120 described in RFC 1157 [RFC1157]. A second version of the SNMP 121 message protocol, which is not an Internet standards track 122 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 123 and RFC 1906 [RFC1906]. The third version of the message 124 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 125 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 127 o Protocol operations for accessing management information. The 128 first set of protocol operations and associated PDU formats is 129 described in RFC 1157 [RFC1157]. A second set of protocol 130 operations and associated PDU formats is described in RFC 1905 131 [RFC1905]. 133 o A set of fundamental applications described in RFC 2573 134 [RFC2573] and the view-based access control mechanism described 135 in RFC 2575 [RFC2575]. 137 A more detailed introduction to the current SNMP Management Framework 138 can be found in RFC 2570 [RFC2570]. 140 Managed objects are accessed via a virtual information store, termed 141 the Management Information Base or MIB. Objects in the MIB are 142 defined using the mechanisms defined in the SMI. 144 This memo does not specify a MIB module. 146 5. Overview 148 The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to 149 globally identify individual protocol encapsulations in the 150 protocolDirTable. 152 This guide contains algorithms and the authoritative set of base layer 153 protocol identifier macros, for use within INDEX values in the 154 protocolDirTable. 156 This is the the second revision of this document, and is intended to 157 replace the first half the RMON-2 Protocol Identifiers document 158 [RFC2074]. 160 5.1. Terms 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 Several terms are used throughout this document, as well as in the 167 RMON-2 MIB [RFC2021], that should be introduced: 169 parent protocol: 170 Also called 'parent'; The encapsulating protocol identifier for a 171 specific protocol layer, e.g., IP is the parent protocol of UDP. 172 Note that base layers cannot have parent protocols. This term may 173 be used to refer to a specific encapsulating protocol, or it may be 174 used generically to refer to any encapsulating protocol. 176 child protocol: 177 Also called 'child'; An encapsulated protocol identifier for a 178 specific protocol layer. e.g., UDP is a child protocol of IP. This 179 term may be used to refer to a specific encapsulated protocol, or 180 it may be used generically to refer to any encapsulated protocol. 182 layer-identifier: 183 An octet string fragment representing a particular protocol 184 encapsulation layer or sub-layer. A fragment consists of exactly 185 four octets, encoded in network byte order. If present, child 186 layer-identifiers for a protocol MUST have unique values among each 187 other. (See section 6.3 for more details.) 189 protocol: 190 A particular protocol layer, as specified by encoding rules in this 191 document. Usually refers to a single layer in a given 192 encapsulation. Note that this term is sometimes used in the RMON-2 193 MIB [RFC2021] to name a fully-specified protocol-identifier string. 194 In such a case, the protocol-identifier string is named for its 195 upper-most layer. A named protocol may also refer to any 196 encapsulation of that protocol. 198 protocol-identifier string: 199 An octet string representing a particular protocol encapsulation, 200 as specified by the encoding rules in this document. This string is 201 identified in the RMON-2 MIB [RFC2021] as the protocolDirID object. 202 A protocol-identifier string is composed of one or more layer- 203 identifiers read from left to right. The left-most layer- 204 identifier specifies a base layer encapsulation. Each layer- 205 identifier to the right specifies a child layer protocol 206 encapsulation. 208 protocol-identifier macro: 209 Also called a PI macro; A macro-like textual construct used to 210 describe a particular networking protocol. Only protocol attributes 211 which are important for RMON use are documented. Note that the term 212 'macro' is historical, and PI macros are not real macros, nor are 213 they ASN.1 macros. The current set of published RMON PI macros can 214 be found in the RMON Protocol Identifier Macros document 215 [RMONPROT_MAC]. 217 The PI macro serves several purposes: 219 - Names the protocol for use within the RMON-2 MIB [RFC2021]. 220 - Describes how the protocol is encoded into an octet string. 221 - Describes how child protocols are identified (if applicable), 222 and encoded into an octet string. 223 - Describes which protocolDirParameters are allowed for the protocol. 224 - Describes how the associated protocolDirType object is encoded 225 for the protocol. 226 - Provides reference(s) to authoritative documentation for the 227 protocol. 229 protocol-variant-identifier macro: 230 Also called a PI-variant macro; A special kind of PI macro, used to 231 describe a particular protocol layer, which cannot be identified 232 with a deterministic, and (usually) hierarchical structure, like 233 most networking protocols. 235 Note that the PI-variant macro and the PI-macro are defined with a 236 single set of syntax rules (see section 6.2), except that different 237 sub-clauses are required for each type. 239 A protocol identified with a PI-variant macro is actually a variant 240 of a well known encapsulation that may be present in the 241 protocolDirTable. This is used to document the IANA assigned 242 protocols, which are needed to identify protocols which cannot be 243 practically identified by examination of 'appropriate network 244 traffic' (e.g. the packets which carry them). All other protocols 245 (which can be identified by examination of appropriate network 246 traffic) SHOULD be documented using the protocol-identifier macro. 247 (See section 6.2 for details.) 249 protocol-parameter: 250 A single octet, corresponding to a specific layer-identifier in the 251 protocol-identifier. This octet is a bit-mask indicating special 252 functions or capabilities that this agent is providing for the 253 corresponding protocol. (See section 6.2.6 for details.) 255 protocol-parameters string: 256 An octet string, which contains one protocol-parameter for each 257 layer-identifier in the protocol-identifier. This string is 258 identified in the RMON-2 MIB [RFC2021] as the protocolDirParameters 259 object. (See the section 6.2.6 for details.) 261 protocolDirTable INDEX: 262 A protocol-identifier and protocol-parameters octet string pair 263 that have been converted to an INDEX value, according to the 264 encoding rules in in section 7.7 of RFC 1902 [RFC1902]. 266 pseudo-protocol: 267 A convention or algorithm used only within this document for the 268 purpose of encoding protocol-identifier strings. 270 protocol encapsulation tree: 271 Protocol encapsulations can be organized into an inverted rooted 272 tree. The nodes of the root are the base encapsulations. The 273 children nodes, if any, of a node in the tree are the 274 encapsulations of child protocols. 276 5.2. Relationship to the Remote Network Monitoring MIB 278 This document is intended to identify the encoding rules for the OCTET 279 STRING objects protocolDirID and protocolDirParameters. RMON-2 tables, 280 such as those in the new Protocol Distribution, Host, and Matrix groups, 281 use a local INTEGER INDEX (protocolDirLocalIndex) rather than complete 282 protocolDirTable INDEX strings, to identify protocols for counting 283 purposes. Only the protocolDirTable uses the protocolDirID and 284 protocolDirParameters strings described in this document. 286 This document is intentionally separated from the RMON-2 MIB objects 287 [RFC2021] to allow updates to this document without any republication of 288 MIB objects. 290 This document does not discuss auto-discovery and auto-population of the 291 protocolDirTable. This functionality is not explicitly defined by the 292 RMON standard. An agent SHOULD populate the directory with the 293 'interesting' protocols on which the intended applications depend. 295 5.3. Relationship to the RMON Protocol Identifier Macros Document 297 The original RMON Protocol Identifiers document [RFC2074] contains the 298 protocol directory reference material, as well as many examples of 299 protocol identifier macros. 301 These macros have been moved to a separate document called the RMON 302 Protocol Identifier Macros document [RMONPROT_MAC]. This will allow the 303 normative text (this document) to advance on the standards track with 304 the RMON-2 MIB [RFC2021], while the collection of PI macros is 305 maintained in an Informational RFC. 307 The PI Macros document is intentionally separated from this document to 308 allow frequent updates to the list of published PI macros without any 309 republication of MIB objects or encoding rules. Protocol Identifier 310 macros submitted from the RMON working group and community at large (to 311 the RMONMIB WG mailing list at 'rmonmib@cisco.com') will be collected, 312 screened by the RMONMIB working group, and (if approved) added to a 313 subsequent version of the PI Macros document. 315 Macros submissions will be collected in the IANA's MIB files under the 316 directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the 317 RMONMIB working group mailing list message archive file 318 "ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib". 320 5.4. Relationship to the ATM-RMON MIB 322 The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM 323 Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides RMON- 324 like stats, host, matrix, and matrixTopN capability for NSAP address- 325 based (ATM Adaption Layer 5, AAL-5) cell traffic. 327 5.4.1. Port Aggregation 329 It it possible to correlate ATM-RMON MIB data with packet-based RMON-2 330 [RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and 331 'portSelTable' are configured to provide the same level of port 332 aggregation as used in the packet-based collection. This will require 333 an ATM-RMON 'portSelectGroup' to contain a single port, in the case of 334 traditional RMON dataSources. 336 5.4.2. Encapsulation Mappings 338 The RMON PI document does not contain explicit PI macro support for 339 "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or 340 ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, 341 a probe must 'fit' the ATM encapsulation to one of the base layers 342 defined in this document (i.e., llc, snap, or vsnap), regardless of how 343 the raw data is obtained by the agent (e.g., VC-muxing vs. LLC-muxing, 344 or routed vs. bridged formats). See section 6.2 for details on 345 identifying and decoding a particular base layer. 347 An NMS can determine some of the omitted encapsulation details by 348 examining the interface type (ifType) of the dataSource for a particular 349 RMON collection: 351 RFC 1483 dataSource ifTypes: 352 - aal5(49) 354 LANE dataSource ifTypes: 355 - aflane8023(59) 356 - aflane8025(60) 358 These dataSources require implementation of the ifStackTable from the 359 Interfaces MIB [RFC2233]. It is possible that some implementations will 360 use dataSource values which indicate an ifType of 'atm(37)' (because the 361 ifStackTable is not supported), however this is strongly discouraged by 362 the RMONMIB WG. 364 5.4.3. Counting ATM Traffic in RMON-2 Collections 366 The RMON-2 Application Layer (AL) and Network Layer (NL) 367 (host/matrix/topN) tables require that octet counters be incremented by 368 the size of the particular frame, not by the size of the frame 369 attributed to a given protocol. 371 Probe implementations must use the AAL-5 frame size (not the AAL-5 372 payload size or encapsulated MAC frame size) as the 'frame size' for the 373 purpose of incrementing RMON-2 octet counters (e.g., 'nlHostInOctets', 374 'alHostOutOctets'). 376 The RMONMIB WG has not addressed issues relating to packet capture of 377 AAL-5 based traffic. Therefore, it is an implementation-specific matter 378 whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3 or 802.5 379 traffic, or LANE traffic) are represented in the RMON-1 380 'captureBufferPacketData' MIB object. Normally, the first octet of the 381 captured frame is the first octet of the destination MAC address (DA). 383 5.5. Relationship to Other MIBs 385 The RMON Protocol Identifiers Reference document is intended for use 386 with the protocolDirTable within the RMON MIB. It is not relevant to any 387 other MIB, or intended for use with any other MIB. 389 6. Protocol Identifier Encoding 391 The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and 392 protocolDirParameters. To encode the table index, each variable-length 393 string is converted to an OBJECT IDENTIFIER fragment, according to the 394 encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index 395 fragments are simply concatenated. (Refer to figures 1a - 1d below for 396 more detail.) 398 The first OCTET STRING (protocolDirID) is composed of one or more 399 4-octet "layer-identifiers". The entire string uniquely identifies a 400 particular node in the protocol encapsulation tree. The second OCTET 401 STRING, (protocolDirParameters) which contains a corresponding number of 402 1-octet protocol-specific parameters, one for each 4-octet layer- 403 identifier in the first string. 405 A protocol layer is normally identified by a single 32-bit value. Each 406 layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as 407 four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of 408 the 32-bit value in network byte order. If a particular protocol layer 409 cannot be encoded into 32 bits, then it must be defined as an 410 'ianaAssigned' protocol (see below for details on IANA assigned 411 protocols). 413 The following figures show the differences between the OBJECT IDENTIFIER 414 and OCTET STRING encoding of the protocol identifier string. 416 Fig. 1a 417 protocolDirTable INDEX Format 418 ----------------------------- 420 +---+--------------------------+---+---------------+ 421 | c ! | c ! protocolDir | 422 | n ! protocolDirID | n ! Parameters | 423 | t ! | t ! | 424 +---+--------------------------+---+---------------+ 426 Fig. 1b 427 protocolDirTable OCTET STRING Format 428 ------------------------------------ 430 protocolDirID 431 +----------------------------------------+ 432 | | 433 | 4 * N octets | 434 | | 435 +----------------------------------------+ 437 protocolDirParameters 438 +----------+ 439 | | 440 | N octets | 441 | | 442 +----------+ 444 N is the number of protocol-layer-identifiers required 445 for the entire encapsulation of the named protocol. Note 446 that the layer following the base layer usually identifies 447 a network layer protocol, but this is not always the case, 448 (most notably for children of the 'vsnap' base-layer). 450 Fig. 1c 451 protocolDirTable INDEX Format Example 452 ------------------------------------- 454 protocolDirID protocolDirParameters 455 +---+--------+--------+--------+--------+---+---+---+---+---+ 456 | c | proto | proto | proto | proto | c |par|par|par|par| 457 | n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5| 458 | t |(+flags)| L3 | L4 | L5 | t |se | | | | 459 +---+--------+--------+--------+--------+---+---+---+---+---+ subOID 460 | 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count 462 When encoded in a protocolDirTable INDEX, each of the two 463 strings must be preceded by a length sub-component. In this 464 example, N equals '4', the first 'cnt' field would contain 465 the value '16', and the second 'cnt' field would contain 466 the value '4'. 468 Fig. 1d 469 protocolDirTable OCTET STRING Format Example 470 -------------------------------------------- 472 protocolDirID 473 +--------+--------+--------+--------+ 474 | proto | proto | proto | proto | 475 | base | L3 | L4 | L5 | 476 | | | | | 477 +--------+--------+--------+--------+ octet 478 | 4 | 4 | 4 | 4 | count 480 protocolDirParameters 481 +---+---+---+---+ 482 |par|par|par|par| 483 |ba-| L3| L4| L5| 484 |se | | | | 485 +---+---+---+---+ octet 486 | 1 | 1 | 1 | 1 | count 488 Although this example indicates four encapsulated protocols, in 489 practice, any non-zero number of layer-identifiers may be present, 490 theoretically limited only by OBJECT IDENTIFIER length restrictions, as 491 specified in section 3.5 of RFC 1902 [RFC1902]. 493 Note that these two strings would not be concatenated together if ever 494 returned in a GetResponse PDU, since they are different MIB objects. 495 However, protocolDirID and protocolDirParameters are not currently 496 readable MIB objects. 498 6.1. ProtocolDirTable INDEX Format Examples 500 The following PI identifier fragments are examples of some fully encoded 501 protocolDirTable INDEX values for various encapsulations. 503 -- HTTP; fragments counted from IP and above 504 ether2.ip.tcp.www-http = 505 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0 507 -- SNMP over UDP/IP over SNAP 508 snap.ip.udp.snmp = 509 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 511 -- SNMP over IPX over SNAP 512 snap.ipx.snmp = 513 12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0 515 -- SNMP over IPX over raw8023 516 ianaAssigned.ipxOverRaw8023.snmp = 517 12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0 519 -- IPX over LLC 520 llc.ipx = 521 8.0.0.0.2.0.0.0.224.2.0.0 523 -- SNMP over UDP/IP over any link layer 524 ether2.ip.udp.snmp 525 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0 527 -- IP over any link layer; base encoding is IP over ether2 528 ether2.ip 529 8.1.0.0.1.0.0.8.0.2.0.0 531 -- AppleTalk Phase 2 over ether2 532 ether2.atalk 533 8.0.0.0.1.0.0.128.155.2.0.0 535 -- AppleTalk Phase 2 over vsnap 536 vsnap.apple-oui.atalk 537 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0 539 6.2. Protocol Identifier Macro Format 541 The following example is meant to introduce the protocol-identifier 542 macro. This macro-like construct is used to represent both protocols and 543 protocol-variants. 545 If the 'VariantOfPart' component of the macro is present, then the macro 546 represents a protocol-variant instead of a protocol. This clause is 547 currently used only for IANA assigned protocols, enumerated under the 548 'ianaAssigned' base-layer. The VariantOfPart component MUST be present 549 for IANA assigned protocols. 551 6.2.1. Lexical Conventions 553 The PI language defines the following keywords: 555 ADDRESS-FORMAT 556 ATTRIBUTES 557 CHILDREN 558 DECODING 559 DESCRIPTION 560 PARAMETERS 561 PROTOCOL-IDENTIFIER 562 REFERENCE 563 VARIANT-OF 565 The PI language defines the following punctuation elements: 567 { left curly brace 568 } right curly brace 569 ( left parenthesis 570 ) right parenthesis 571 , comma 572 ::= two colons and an equal sign 573 -- two dashes 575 6.2.2. Notation for Syntax Descriptions 577 An extended form of the BNF notation is used to specify the syntax of 578 the PI language. The rules for this notation are shown below: 580 * Literal values are specified in quotes, for example "REFERENCE" 582 * Non-terminal items are surrounded by less than (<) and greater than 583 (>) characters, for example 585 * Terminal items are specified without surrounding quotes or less 586 than and greater than characters, for example 'lcname' 588 * A vertical bar (|) is used to indicate a choice between items, for 589 example 'number | hstr' 591 * Ellipsis are used to indicate that the previous item may be 592 repeated one or more times, for example ... 594 * Square brackets are used to enclose optional items, for example [ 595 "," ] 597 * An equals character (=) is used to mean "defined as," for example 598 ' = pname' 600 6.2.3. Grammar for the PI Language 602 The following are "terminals" of the grammar and are identical to the 603 same lexical elements from the MIB module language, except for hstr and 604 pname: 606 = "a" | "b" | "c" | ... | "z" 607 = "A" | "B" | "C" | ... | "Z" 608 = | 609 = "0" | "1" | ... | "9" 610 = | "a" | "A" | "b" | "B" | ... | "f" | "F" 612 = [ ] 613 = ( | | "-" ) [ ] 615 = ( | ) [ ] 616 = ( | | "-" | "_" | "*" ) [ ] 618 = [ ] -- to a max dec. value of 4g-1 620 = "0x" -- to a max dec. value of 4g-1 621 = [ ] 623 = linefeed char 624 = carriage return char 625 = | 627 = " " 628 = " " 629 = { | | } [] 631 = """ [ ] """ 632 = ( | | ) [ ] 634 The following is the extended BNF notation for the grammar with starting 635 symbol : 637 -- a file containing one or more Protocol Identifier (PI) definitions 638 = ... 640 -- a PI definition 641 = 642 "PROTOCOL-IDENTIFIER" 643 [ "VARIANT-OF" ] 644 "PARAMETERS" "{" [ ] "}" 645 "ATTRIBUTES" "{" [ ] "}" 646 "DESCRIPTION" string 647 [ "CHILDREN" string ] 648 [ "ADDRESS-FORMAT" string ] 649 [ "DECODING" string ] 650 [ "REFERENCE" string ] 651 "::=" "{" "}" 653 -- a protocol name 654 = pname 656 -- a list of parameters 657 = [ "," ]... 659 -- a parameter 660 = lcname [] "(" [] 661 [] ")" [] 663 -- list of attributes 664 = [ [] "," [] ]... 666 -- an attribute 667 = lcname [] "(" [] 668 [] ")" 670 -- a non-negative number 671 = number | hstr 673 -- list of encapsulation values 674 = [ [] "," 675 [] ]... 677 -- an encapsulation value 678 = | 680 -- base encapsulation value 681 = 683 -- normal encapsulation value 684 = 686 -- comment 687 689 6.2.4. Mapping of the Protocol Name 691 The "protoName" value, called the "protocol name" shall be an ASCII 692 string consisting of one up to 64 characters from the following: 694 "A" through "Z" 695 "a" through "z" 696 "0" through "9" 697 dash (-) 698 underbar (_) 699 asterisk (*) 700 plus(+) 702 The first character of the protocol name is limited to one of the 703 following: 705 "A" through "Z" 706 "a" through "z" 707 "0" through "9" 709 This value SHOULD be the name or acronym identifying the protocol. Note 710 that case is significant. The value selected for the protocol name 711 SHOULD match the "most well-known" name or acronym for the indicated 712 protocol. For example, the document indicated by the URL: 714 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 716 defines IP Protocol field values, so protocol-identifier macros for 717 children of IP SHOULD be given names consistent with the protocol names 718 found in this authoritative document. Likewise, children of UDP and TCP 719 SHOULD be given names consistent with the port number name assignments 720 found in: 722 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers 724 When the "well-known name" contains characters not allowed in protocol 725 names, they MUST be changed to a dash character ("-") . In the event 726 that the first character must be changed, the protocol name is prepended 727 with the letter "p", so the former first letter may be changed to a 728 dash. 730 For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The 731 following protocol names are legal: 733 ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu 735 Note that it is possible in actual implementation that different 736 encapsulations of the same protocol (which are represented by different 737 entries in the protocolDirTable) will be assigned the same protocol 738 name. The protocolDirID INDEX value defines a particular protocol, not 739 the protocol name string. 741 6.2.5. Mapping of the VARIANT-OF Clause 743 This clause is present for IANA assigned protocols only. It identifies 744 the protocol-identifier macro that most closely represents this 745 particular protocol, and is known as the "reference protocol". A 746 protocol-identifier macro MUST exist for the reference protocol. When 747 this clause is present in a protocol-identifier macro, the macro is 748 called a 'protocol-variant-identifier'. 750 Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol- 751 identifier macro SHOULD NOT be duplicated in the protocol-variant- 752 identifier macro, if the 'variant' protocols' semantics are identical 753 for a given clause. 755 Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a 756 protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e. 757 "PARAMETERS {}") MUST be present in a protocol-variant-identifier macro, 758 and the 'ParamList' and 'AttrList' found in the reference protocol- 759 identifier macro examined instead. 761 Note that if an 'ianaAssigned' protocol is defined that is not a variant 762 of any other documented protocol, then the protocol-identifier macro 763 SHOULD be used instead of the protocol-variant-identifier version of the 764 macro. 766 6.2.6. Mapping of the PARAMETERS Clause 768 The protocolDirParameters object provides an NMS the ability to turn on 769 and off expensive probe resources. An agent may support a given 770 parameter all the time, not at all, or subject to current resource load. 772 The PARAMETERS clause is a list of bit definitions which can be directly 773 encoded into the associated ProtocolDirParameters octet in network byte 774 order. Zero or more bit definitions may be present. Only bits 0-7 are 775 valid encoding values. This clause defines the entire BIT set allowed 776 for a given protocol. A conforming agent may choose to implement a 777 subset of zero or more of these PARAMETERS. 779 By convention, the following common bit definitions are used by 780 different protocols. These bit positions MUST NOT be used for other 781 parameters. They MUST be reserved if not used by a given protocol. 783 Bits are encoded in a single octet. Bit 0 is the high order (left-most) 784 bit in the octet, and bit 7 is the low order (right-most) bit in the 785 first octet. Reserved bits and unspecified bits in the octet are set to 786 zero. 788 Table 3.1 Reserved PARAMETERS Bits 789 ------------------------------------ 791 Bit Name Description 792 --------------------------------------------------------------------- 793 0 countsFragments higher-layer protocols encapsulated within 794 this protocol will be counted correctly even 795 if this protocol fragments the upper layers 796 into multiple packets. 797 1 tracksSessions correctly attributes all packets of a protocol 798 which starts sessions on well known ports or 799 sockets and then transfers them to dynamically 800 assigned ports or sockets thereafter (e.g. TFTP). 802 The PARAMETERS clause MUST be present in all protocol-identifier macro 803 declarations, but may be equal to zero (empty). 805 6.2.6.1. Mapping of the 'countsFragments(0)' BIT 807 This bit indicates whether the probe is correctly attributing all 808 fragmented packets of the specified protocol, even if individual frames 809 carrying this protocol cannot be identified as such. Note that the 810 probe is not required to actually present any re-assembled datagrams 811 (for address-analysis, filtering, or any other purpose) to the NMS. 813 This bit MUST only be set in a protocolDirParameters octet which 814 corresponds to a protocol that supports fragmentation and reassembly in 815 some form. Note that TCP packets are not considered 'fragmented-streams' 816 and so TCP is not eligible. 818 This bit MAY be set in more than one protocolDirParameters octet within 819 a protocolDirTable INDEX, in the event an agent can count fragments at 820 more than one protocol layer. 822 6.2.6.2. Mapping of the 'tracksSessions(1)' BIT 824 The 'tracksSessions(1)' bit indicates whether frames which are part of 825 remapped-sessions (e.g. TFTP download sessions) are correctly counted by 826 the probe. For such a protocol, the probe must usually analyze all 827 packets received on the indicated interface, and maintain some state 828 information, (e.g. the remapped UDP port number for TFTP). 830 The semantics of the 'tracksSessions' parameter are independent of the 831 other protocolDirParameters definitions, so this parameter MAY be 832 combined with any other legal parameter configurations. 834 6.2.7. Mapping of the ATTRIBUTES Clause 836 The protocolDirType object provides an NMS with an indication of a 837 probe's capabilities for decoding a given protocol, or the general 838 attributes of the particular protocol. 840 The ATTRIBUTES clause is a list of bit definitions which are encoded 841 into the associated instance of ProtocolDirType. The BIT definitions are 842 specified in the SYNTAX clause of the protocolDirType MIB object. 844 Table 3.2 Reserved ATTRIBUTES Bits 845 ------------------------------------ 847 Bit Name Description 848 --------------------------------------------------------------------- 849 0 hasChildren indicates that there may be children of 850 this protocol defined in the protocolDirTable 851 (by either the agent or the manager). 852 1 addressRecognitionCapable 853 indicates that this protocol can be used 854 to generate host and matrix table entries. 856 The ATTRIBUTES clause MUST be present in all protocol-identifier macro 857 declarations, but MAY be empty. 859 6.2.8. Mapping of the DESCRIPTION Clause 861 The DESCRIPTION clause provides a textual description of the protocol 862 identified by this macro. Notice that it SHOULD NOT contain details 863 about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and 864 REFERENCE clauses. 866 The DESCRIPTION clause MUST be present in all protocol-identifier macro 867 declarations. 869 6.2.9. Mapping of the CHILDREN Clause 871 The CHILDREN clause provides a description of child protocols for 872 protocols which support them. It has three sub-sections: 874 - Details on the field(s)/value(s) used to select the child protocol, 875 and how that selection process is performed 877 - Details on how the value(s) are encoded in the protocol identifier 878 octet string 880 - Details on how child protocols are named with respect to their 881 parent protocol label(s) 883 The CHILDREN clause MUST be present in all protocol-identifier macro 884 declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES 885 clause. 887 6.2.10. Mapping of the ADDRESS-FORMAT Clause 889 The ADDRESS-FORMAT clause provides a description of the OCTET-STRING 890 format(s) used when encoding addresses. 892 This clause MUST be present in all protocol-identifier macro 893 declarations in which the 'addressRecognitionCapable(1)' BIT is set in 894 the ATTRIBUTES clause. 896 6.2.11. Mapping of the DECODING Clause 898 The DECODING clause provides a description of the decoding procedure for 899 the specified protocol. It contains useful decoding hints for the 900 implementor, but SHOULD NOT over-replicate information in documents 901 cited in the REFERENCE clause. It might contain a complete description 902 of any decoding information required. 904 For 'extensible' protocols ('hasChildren(0)' BIT set) this includes 905 offset and type information for the field(s) used for child selection as 906 well as information on determining the start of the child protocol. 908 For 'addressRecognitionCapable' protocols this includes offset and type 909 information for the field(s) used to generate addresses. 911 The DECODING clause is optional, and MAY be omitted if the REFERENCE 912 clause contains pointers to decoding information for the specified 913 protocol. 915 6.2.12. Mapping of the REFERENCE Clause 917 If a publicly available reference document exists for this protocol it 918 SHOULD be listed here. Typically this will be a URL if possible; if not 919 then it will be the name and address of the controlling body. 921 The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the 922 amount of information which may currently be obtained from an 923 authoritative document, such as the Assigned Numbers document [RFC1700]. 924 Any duplication or paraphrasing of information should be brief and 925 consistent with the authoritative document. 927 The REFERENCE clause is optional, but SHOULD be implemented if an 928 authoritative reference exists for the protocol (especially for standard 929 protocols). 931 6.3. Evaluating an Index of the ProtocolDirectoryTable 933 The following evaluation is done after protocolDirTable INDEX value has 934 been converted into two OCTET STRINGs according to the INDEX encoding 935 rules specified in the SMI [RFC1902]. 937 Protocol-identifiers are evaluated left to right, starting with the 938 protocolDirID, which length MUST be evenly divisible by four. The 939 protocolDirParameters length MUST be exactly one quarter of the 940 protocolDirID string length. 942 Protocol-identifier parsing starts with the base layer identifier, which 943 MUST be present, and continues for one or more upper layer identifiers, 944 until all OCTETs of the protocolDirID have been used. Layers MAY NOT be 945 skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can 946 not exist. 948 The base-layer-identifier also contains a 'special function identifier' 949 which may apply to the rest of the protocol identifier. 951 Wild-carding at the base layer within a protocol encapsulation is the 952 only supported special function at this time. (See section 7.1.1.2 for 953 details.) 955 After the protocol-identifier string (which is the value of 956 protocolDirID) has been parsed, each octet of the protocol-parameters 957 string is evaluated, and applied to the corresponding protocol layer. 959 A protocol-identifier label MAY map to more than one value. For 960 instance, 'ip' maps to 5 distinct values, one for each supported 961 encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers' in 962 the RMON Protocol Identifier Macros document [RMONPROT_MAC]). 964 It is important to note that these macros are conceptually expanded at 965 implementation time, not at run time. 967 If all the macros are expanded completely by substituting all possible 968 values of each label for each child protocol, a list of all possible 969 protocol-identifiers is produced. So 'ip' would result in 5 distinct 970 protocol-identifiers. Likewise each child of 'ip' would map to at least 971 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, 972 ip over LLC, etc.). 974 7. Base Layer Protocol Identifier Macros 976 The following PROTOCOL IDENTIFIER macros can be used to construct 977 protocolDirID and protocolDirParameters strings. 979 An identifier is encoded by constructing the base-identifier, then 980 adding one layer-identifier for each encapsulated protocol. 982 Refer to the RMON Protocol Identifier Macros document [RMONPROT_MAC] for 983 a listing of the non-base layer PI macros published by the working 984 group. Note that other PI macro documents may exist, and it should be 985 possible for an implementor to populate the protocolDirTable without the 986 use of the PI Macro document [RMONPROT_MAC]. 988 7.1. Base Identifier Encoding 990 The first layer encapsulation is called the base identifier and it 991 contains optional protocol-function information and the base layer (e.g. 992 MAC layer) enumeration value used in this protocol identifier. 994 The base identifier is encoded as four octets as shown in figure 2. 996 Fig. 2 997 base-identifier format 998 +---+---+---+---+ 999 | | | | | 1000 | f |op1|op2| m | 1001 | | | | | 1002 +---+---+---+---+ octet 1003 | 1 | 1 | 1 | 1 | count 1005 The first octet ('f') is the special function code, found in table 4.1. 1006 The next two octets ('op1' and 'op2') are operands for the indicated 1007 function. If not used, an operand must be set to zero. The last octet, 1008 'm', is the enumerated value for a particular base layer encapsulation, 1009 found in table 4.2. All four octets are encoded in network-byte-order. 1011 7.1.1. Protocol Identifier Functions 1013 The base layer identifier contains information about any special 1014 functions to perform during collections of this protocol, as well as the 1015 base layer encapsulation identifier. 1017 The first three octets of the identifier contain the function code and 1018 two optional operands. The fourth octet contains the particular base 1019 layer encapsulation used in this protocol (fig. 2). 1021 Table 4.1 Assigned Protocol Identifier Functions 1022 ------------------------------------------------- 1024 Function ID Param1 Param2 1025 ---------------------------------------------------- 1026 none 0 not used (0) not used (0) 1027 wildcard 1 not used (0) not used (0) 1029 7.1.1.1. Function 0: None 1031 If the function ID field (1st octet) is equal to zero, the 'op1' and 1032 'op2' fields (2nd and 3rd octets) must also be equal to zero. This 1033 special value indicates that no functions are applied to the protocol 1034 identifier encoded in the remaining octets. The identifier represents a 1035 normal protocol encapsulation. 1037 7.1.1.2. Function 1: Protocol Wildcard Function 1039 The wildcard function (function-ID = 1), is used to aggregate counters, 1040 by using a single protocol value to indicate potentially many base layer 1041 encapsulations of a particular network layer protocol. A 1042 protocolDirEntry of this type will match any base-layer encapsulation of 1043 the same network layer protocol. 1045 The 'op1' field (2nd octet) is not used and MUST be set to zero. 1047 The 'op2' field (3rd octet) is not used and MUST be set to zero. 1049 Each wildcard protocol identifier MUST be defined in terms of a 'base 1050 encapsulation'. This SHOULD be as 'standard' as possible for 1051 interoperability purposes. The lowest possible base layer value SHOULD 1052 be chosen. So, if an encapsulation over 'ether2' is permitted, than 1053 this should be used as the base encapsulation. 1055 If not then an encapsulation over LLC should be used, if permitted. And 1056 so on for each of the defined base layers. It should be noted that an 1057 agent does not have to support the non-wildcard protocol identifier over 1058 the same base layer. For instance a token ring only device would not 1059 normally support IP over the ether2 base layer. Nevertheless it should 1060 use the ether2 base layer for defining the wildcard IP encapsulation. 1061 The agent MAY also support counting some or all of the individual 1062 encapsulations for the same protocols, in addition to wildcard counting. 1063 Note that the RMON-2 MIB [RFC2021] does not require that agents maintain 1064 counters for multiple encapsulations of the same protocol. It is an 1065 implementation-specific matter as to how an agent determines which 1066 protocol combinations to allow in the protocolDirTable at any given 1067 time. 1069 7.2. Base Layer Protocol Identifiers 1071 The base layer is mandatory, and defines the base encapsulation of the 1072 packet and any special functions for this identifier. 1074 There are no suggested protocolDirParameters bits for the base layer. 1076 The suggested value for the ProtocolDirDescr field for the base layer is 1077 given by the corresponding "Name" field in the table 4.2 below. However, 1078 implementations are only required to use the appropriate integer 1079 identifier values. 1081 For most base layer protocols, the protocolDirType field should contain 1082 bits set for the 'hasChildren(0)' and 'addressRecognitionCapable(1)' 1083 attributes. However, the special 'ianaAssigned' base layer should have 1084 no parameter or attribute bits set. 1086 By design, only 255 different base layer encapsulations are supported. 1087 There are five base encapsulation values defined at this time. Very few 1088 new base encapsulations (e.g. for new media types) are expected to be 1089 added over time. 1091 Table 4.2 Base Layer Encoding Values 1092 -------------------------------------- 1094 Name ID 1095 ------------------ 1096 ether2 1 1097 llc 2 1098 snap 3 1099 vsnap 4 1100 ianaAssigned 5 1102 -- Ether2 Encapsulation 1104 ether2 PROTOCOL-IDENTIFIER 1105 PARAMETERS { } 1106 ATTRIBUTES { 1107 hasChildren(0), 1108 addressRecognitionCapable(1) 1109 } 1110 DESCRIPTION 1111 "DIX Ethernet, also called Ethernet-II." 1112 CHILDREN 1113 "The Ethernet-II type field is used to select child protocols. 1114 This is a 16-bit field. Child protocols are deemed to start at 1115 the first octet after this type field. 1117 Children of this protocol are encoded as [ 0.0.0.1 ], the 1118 protocol identifier for 'ether2' followed by [ 0.0.a.b ] where 1119 'a' and 'b' are the network byte order encodings of the high 1120 order byte and low order byte of the Ethernet-II type value. 1122 For example, a protocolDirID-fragment value of: 1123 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2. 1125 Children of ether2 are named as 'ether2' followed by the type 1126 field value in hexadecimal. The above example would be declared 1127 as: 1128 ether2 0x0800" 1129 ADDRESS-FORMAT 1130 "Ethernet addresses are 6 octets in network order." 1131 DECODING 1132 "Only type values greater than 1500 decimal indicate Ethernet-II 1133 frames; lower values indicate 802.3 encapsulation (see below)." 1134 REFERENCE 1135 "The authoritative list of Ether Type values is identified by the 1136 URL: 1138 ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers" 1139 ::= { 1 } 1141 -- LLC Encapsulation 1143 llc PROTOCOL-IDENTIFIER 1144 PARAMETERS { } 1145 ATTRIBUTES { 1146 hasChildren(0), 1147 addressRecognitionCapable(1) 1148 } 1149 DESCRIPTION 1150 "The Logical Link Control (LLC) 802.2 protocol." 1151 CHILDREN 1152 "The LLC Source Service Access Point (SSAP) and Destination 1153 Service Access Point (DSAP) are used to select child protocols. 1154 Each of these is one octet long, although the least significant 1155 bit is a control bit and should be masked out in most situations. 1156 Typically SSAP and DSAP (once masked) are the same for a given 1157 protocol - each end implicitly knows whether it is the server or 1158 client in a client/server protocol. This is only a convention, 1159 however, and it is possible for them to be different. The SSAP 1160 is matched against child protocols first. If none is found then 1161 the DSAP is matched instead. The child protocol is deemed to 1162 start at the first octet after the LLC control field(s). 1164 Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol 1165 identifier component for LLC followed by [ 0.0.0.a ] where 'a' is 1166 the SAP value which maps to the child protocol. For example, a 1167 protocolDirID-fragment value of: 1168 0.0.0.2.0.0.0.240 1170 defines NetBios over LLC. 1172 Children are named as 'llc' followed by the SAP value in 1173 hexadecimal. So the above example would have been named: 1174 llc 0xf0" 1175 ADDRESS-FORMAT 1176 "The address consists of 6 octets of MAC address in network 1177 order. Source routing bits should be stripped out of the address 1178 if present." 1179 DECODING 1180 "Notice that LLC has a variable length protocol header; there are 1181 always three octets (DSAP, SSAP, control). Depending on the 1182 value of the control bits in the DSAP, SSAP and control fields 1183 there may be an additional octet of control information. 1185 LLC can be present on several different media. For 802.3 and 1186 802.5 its presence is mandated (but see ether2 and raw 802.3 1187 encapsulations). For 802.5 there is no other link layer 1188 protocol. 1190 Notice also that the raw802.3 link layer protocol may take 1191 precedence over this one in a protocol specific manner such that 1192 it may not be possible to utilize all LSAP values if raw802.3 is 1193 also present." 1194 REFERENCE 1195 "The authoritative list of LLC LSAP values is controlled by the 1196 IEEE Registration Authority: 1197 IEEE Registration Authority 1198 c/o Iris Ringel 1199 IEEE Standards Dept 1200 445 Hoes Lane, P.O. Box 1331 1201 Piscataway, NJ 08855-1331 1202 Phone +1 908 562 3813 1203 Fax: +1 908 562 1571" 1204 ::= { 2 } 1206 -- SNAP over LLC (Organizationally Unique Identifier, OUI=000) Encapsulation 1208 snap PROTOCOL-IDENTIFIER 1209 PARAMETERS { } 1210 ATTRIBUTES { 1211 hasChildren(0), 1212 addressRecognitionCapable(1) 1213 } 1214 DESCRIPTION 1215 "The Sub-Network Access Protocol (SNAP) is layered on top of LLC 1216 protocol, allowing Ethernet-II protocols to be run over a media 1217 restricted to LLC." 1218 CHILDREN 1219 "Children of 'snap' are identified by Ethernet-II type values; 1220 the SNAP Protocol Identifier field (PID) is used to select the 1221 appropriate child. The entire SNAP protocol header is consumed; 1222 the child protocol is assumed to start at the next octet after 1223 the PID. 1225 Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol 1226 identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' 1227 are the high order byte and low order byte of the Ethernet-II 1228 type value. 1230 For example, a protocolDirID-fragment value of: 1231 0.0.0.3.0.0.8.0 1233 defines the IP/SNAP protocol. 1235 Children of this protocol are named 'snap' followed by the 1236 Ethernet-II type value in hexadecimal. The above example would 1237 be named: 1239 snap 0x0800" 1240 ADDRESS-FORMAT 1241 "The address format for SNAP is the same as that for LLC" 1242 DECODING 1243 "SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA 1244 and a single control octet will be present. There are then three 1245 octets of Organizationally Unique Identifier (OUI) and two octets 1246 of PID. For this encapsulation the OUI must be 0x000000 (see 1247 'vsnap' below for non-zero OUIs)." 1248 REFERENCE 1249 "SNAP Identifier values are assigned by the IEEE Standards 1250 Office. The address is: 1251 IEEE Registration Authority 1252 c/o Iris Ringel 1253 IEEE Standards Dept 1254 445 Hoes Lane, P.O. Box 1331 1255 Piscataway, NJ 08855-1331 1256 Phone +1 908 562 3813 1257 Fax: +1 908 562 1571" 1258 ::= { 3 } 1260 -- Vendor SNAP over LLC (OUI != 000) Encapsulation 1262 vsnap PROTOCOL-IDENTIFIER 1263 PARAMETERS { } 1264 ATTRIBUTES { 1265 hasChildren(0), 1266 addressRecognitionCapable(1) 1267 } 1268 DESCRIPTION 1269 "This pseudo-protocol handles all SNAP packets which do not have 1270 a zero OUI. See 'snap' above for details of those that have a 1271 zero OUI value." 1272 CHILDREN 1273 "Children of 'vsnap' are selected by the 3 octet OUI; the PID is 1274 not parsed; child protocols are deemed to start with the first 1275 octet of the SNAP PID field, and continue to the end of the 1276 packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the 1277 protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where 1278 'a', 'b' and 'c' are the 3 octets of the OUI field in network 1279 byte order. 1281 For example, a protocolDirID-fragment value of: 1282 0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols 1283 over vsnap. 1285 Children are named as 'vsnap ', where the '' field is 1286 represented as 3 octets in hexadecimal notation. 1288 So the above example would be named: 1289 'vsnap 0x080007'" 1290 ADDRESS-FORMAT 1291 "The LLC address format is inherited by 'vsnap'. See the 'llc' 1292 protocol identifier for more details." 1293 DECODING 1294 "Same as for 'snap' except the OUI is non-zero and the SNAP 1295 Protocol Identifier is not parsed." 1296 REFERENCE 1297 "SNAP Identifier values are assigned by the IEEE Standards 1298 Office. The address is: 1299 IEEE Registration Authority 1300 c/o Iris Ringel 1301 IEEE Standards Dept 1302 445 Hoes Lane, P.O. Box 1331 1303 Piscataway, NJ 08855-1331 1304 Phone +1 908 562 3813 1305 Fax: +1 908 562 1571" 1306 ::= { 4 } 1308 -- IANA Assigned Protocols 1310 ianaAssigned PROTOCOL-IDENTIFIER 1311 PARAMETERS { } 1312 ATTRIBUTES { } 1313 DESCRIPTION 1314 "This branch contains protocols which do not conform easily to 1315 the hierarchical format utilized in the other link layer 1316 branches. Usually, such a protocol 'almost' conforms to a 1317 particular 'well-known' identifier format, but additional 1318 criteria are used (e.g. configuration-based), making protocol 1319 identification difficult or impossible by examination of 1320 appropriate network traffic (preventing the any 'well-known' 1321 protocol-identifier macro from being used). 1323 Sometimes well-known protocols are simply remapped to a different 1324 port number by one or more venders (e.g. SNMP). These protocols 1325 can be identified with the 'limited extensibility' feature of the 1326 protocolDirTable, and do not need special IANA assignments. 1328 A centrally located list of these enumerated protocols must be 1329 maintained by IANA to insure interoperability. (See section 5.3 1330 for details on the document update procedure.) Support for new 1331 link-layers will be added explicitly, and only protocols which 1332 cannot possibly be represented in a better way will be considered 1333 as 'ianaAssigned' protocols. 1335 IANA protocols are identified by the base-layer-selector value [ 1336 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer 1337 value corresponding to the particular IANA protocol. 1339 Do not create children of this protocol unless you are sure that 1340 they cannot be handled by the more conventional link layers 1341 above." 1342 CHILDREN 1343 "Children of this protocol are identified by implementation- 1344 specific means, described (as best as possible) in the 'DECODING' 1345 clause within the protocol-variant-identifier macro for each 1346 enumerated protocol. 1348 Children of this protocol are encoded as [ 0.0.0.5 ], the 1349 protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ] 1350 where 'a', 'b' are the network byte order encodings of the high 1351 order byte and low order byte of the enumeration value for the 1352 particular IANA assigned protocol. 1354 For example, a protocolDirID-fragment value of: 1355 0.0.0.5.0.0.0.1 1357 defines the IPX protocol encapsulated directly in 802.3 1359 Children are named 'ianaAssigned' followed by the numeric value 1360 of the particular IANA assigned protocol. The above example 1361 would be named: 1363 'ianaAssigned 1' " 1364 DECODING 1365 "The 'ianaAssigned' base layer is a pseudo-protocol and is not 1366 decoded." 1367 REFERENCE 1368 "Refer to individual PROTOCOL-IDENTIFIER macros for information 1369 on each child of the IANA assigned protocol." 1370 ::= { 5 } 1372 -- The following protocol-variant-identifier macro declarations are 1373 -- used to identify the RMONMIB IANA assigned protocols in a proprietary way, 1374 -- by simple enumeration. 1376 ipxOverRaw8023 PROTOCOL-IDENTIFIER 1377 VARIANT-OF ipx 1378 PARAMETERS { } 1379 ATTRIBUTES { } 1380 DESCRIPTION 1381 "This pseudo-protocol describes an encapsulation of IPX over 1382 802.3, without a type field. 1384 Refer to the macro for IPX for additional information about this 1385 protocol." 1386 DECODING 1387 "Whenever the 802.3 header indicates LLC a set of protocol 1388 specific tests needs to be applied to determine whether this is a 1389 'raw8023' packet or a true 802.2 packet. The nature of these 1390 tests depends on the active child protocols for 'raw8023' and is 1391 beyond the scope of this document." 1392 ::= { 1393 ianaAssigned 1, -- [0.0.0.1] 1394 802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1] 1395 } 1397 7.3. Encapsulation Layers 1399 Encapsulation layers are positioned between the base layer and the 1400 network layer. It is an implementation-specific matter whether a probe 1401 exposes all such encapsulations in its RMON-2 Protocol Directory. 1403 7.3.1. IEEE 802.1Q 1405 RMON probes may encounter 'VLAN tagged' frames on monitored links. The 1406 IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and 1407 [IEEE802.1D-1998], define an encapsulation layer inserted after the MAC 1408 layer and before the network layer. This section defines a PI macro 1409 which supports most (but not all) features of that encapsulation layer. 1411 Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring 1412 Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header. It 1413 is an implementation specific matter whether an RMON probe converts LLC- 1414 Token Ring (LLC-TR) formatted frames to LLC-Native (LLC-N) format, for 1415 the purpose of RMON collection. 1417 In order to support the Ethernet and LLC-N formats in the most efficient 1418 manner, and still maintain alignment with the RMON-2 'collapsed' base 1419 layer approach (i.e., support for snap and vsnap), the children of 1420 802dot1Q are encoded a little differently than the children of other 1421 base layer identifiers. 1423 802-1Q PROTOCOL-IDENTIFIER 1424 PARAMETERS { } 1425 ATTRIBUTES { 1426 hasChildren(0) 1427 } 1428 DESCRIPTION 1429 "IEEE 802.1Q VLAN Encapsulation header. 1431 Note that the specific encoding of the TPID field is not 1432 explicitly identified by this PI macro. Ethernet-encoded vs. 1433 SNAP-encoded TPID fields can be identified by the ifType of the 1434 data source for a particular RMON collection, since the SNAP- 1435 encoded format is used exclusively on Token Ring and FDDI media. 1436 Also, no information held in the TCI field (including the TR- 1437 encap bit) is identified in protocolDirID strings utilizing this 1438 PI macro." 1439 CHILDREN 1440 "The first byte of the 4-byte child identifier is used to 1441 distinguish the particular base encoding that follows the 802.1Q 1442 header. The remaining three bytes are used exactly as defined by 1443 the indicated base layer encoding. 1445 In order to simplify the child encoding for the most common 1446 cases, the 'ether2' and 'snap' base layers are combined into a 1447 single identifier, with a value of zero. The other baser layers 1448 are encoded with values taken from Table 4.2. 1450 802-1Q Base ID Values 1451 --------------------- 1453 Base Table 4.2 Base-ID 1454 Layer Encoding Encoding 1455 ------------------------------------- 1456 ether2 1 0 1457 llc 2 2 1458 snap 3 0 1459 vsnap 4 4 1460 ianaAssigned 5 5 1462 The generic child layer-identifier format is shown below: 1464 802-1Q Child Layer-Identifier Format 1465 +--------+--------+--------+--------+ 1466 | Base | | 1467 | ID | base-specific format | 1468 | | | 1469 +--------+--------+--------+--------+ 1470 | 1 | 3 | octet count 1472 Base ID == 0 1473 ------------ 1474 For payloads encoded with either the Ethernet or LLC/SNAP headers 1475 following the VLAN header, children of this protocol are 1476 identified exactly as described for the 'ether2' or 'snap' base 1477 layers. 1479 Children are encoded as [ 0.0.129.0 ], the protocol identifier 1480 for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the 1481 network byte order encodings of the high order byte and low order 1482 byte of the Ethernet-II type value. 1484 For example, a protocolDirID-fragment value of: 1485 0.0.0.1.0.0.129.0.0.0.8.0 1487 defines IP, VLAN-encapsulated in ether2. 1489 Children of this format are named as '802-1Q' followed by the 1490 type field value in hexadecimal. 1492 So the above example would be declared as: 1493 '802-1Q 0x0800'. 1495 Base ID == 2 1496 ------------ 1497 For payloads encoded with a (non-SNAP) LLC header following the 1498 VLAN header, children of this protocol are identified exactly as 1499 described for the 'llc' base layer. 1501 Children are encoded as [ 0.0.129.0 ], the protocol identifier 1502 component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the 1503 SAP value which maps to the child protocol. For example, a 1504 protocolDirID-fragment value of: 1505 0.0.0.1.0.0.129.0.2.0.0.240 1507 defines NetBios, VLAN-encapsulated over LLC. 1509 Children are named as '802-1Q' followed by the SAP value in 1510 hexadecimal, with the leading octet set to the value 2. 1512 So the above example would have been named: 1513 '802-1Q 0x020000f0' 1515 Base ID == 4 1516 ------------ 1517 For payloads encoded with LLC/SNAP (non-zero OUI) headers 1518 following the VLAN header, children of this protocol are 1519 identified exactly as described for the 'vsnap' base layer. 1521 Children are encoded as [ 0.0.129.0 ], the protocol identifier 1522 for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are 1523 the 3 octets of the OUI field in network byte order. 1525 For example, a protocolDirID-fragment value of: 1526 0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of 1527 protocols, VLAN-encapsulated over vsnap. 1529 Children are named as '802-1Q' followed by the value, which 1530 is represented as 3 octets in hexadecimal notation, with a 1531 leading octet set to the value 4. 1533 So the above example would be named: 1534 '802-1Q 0x04080007'. 1536 Base ID == 5 1537 ------------ 1538 For payloads which can only be identified as 'ianaAssigned' 1539 protocols, children of this protocol are identified exactly as 1540 described for the 'ianaAssigned' base layer. 1542 Children are encoded as [ 0.0.129.0 ], the protocol identifier 1543 for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the 1544 network byte order encodings of the high order byte and low order 1545 byte of the enumeration value for the particular IANA assigned 1546 protocol. 1548 For example, a protocolDirID-fragment value of: 1549 0.0.0.1.0.0.129.0.5.0.0.0.1 1551 defines the IPX protocol, VLAN-encapsulated directly in 802.3 1553 Children are named '802-1Q' followed by the numeric value of the 1554 particular IANA assigned protocol, with a leading octet set to 1555 the value of 5. 1557 Children are named '802-1Q' followed by the hexadecimal encoding 1558 of the child identifier. The above example would be named: 1560 '802-1Q 0x05000001'. " 1561 DECODING 1562 "VLAN headers and tagged frame structure are defined in 1563 [IEEE802.1Q]." 1564 REFERENCE 1565 "The 802.1Q Protocol is defined in the Draft Standard for Virtual 1566 Bridged Local Area Networks [IEEE802.1Q]." 1567 ::= { 1568 ether2 0x8100 -- Ethernet or SNAP encoding of TPID 1569 -- snap 0x8100 ** excluded to reduce PD size & complexity 1570 } 1572 8. Intellectual Property 1574 The IETF takes no position regarding the validity or scope of any 1575 intellectual property or other rights that might be claimed to pertain 1576 to the implementation or use of the technology described in this 1577 document or the extent to which any license under such rights might or 1578 might not be available; neither does it represent that it has made any 1579 effort to identify any such rights. Information on the IETF's 1580 procedures with respect to rights in standards-track and standards- 1581 related documentation can be found in BCP-11. Copies of claims of 1582 rights made available for publication and any assurances of licenses to 1583 be made available, or the result of an attempt made to obtain a general 1584 license or permission for the use of such proprietary rights by 1585 implementors or users of this specification can be obtained from the 1586 IETF Secretariat." 1588 The IETF invites any interested party to bring to its attention any 1589 copyrights, patents or patent applications, or other proprietary rights 1590 which may cover technology that may be required to practice this 1591 standard. Please address the information to the IETF Executive 1592 Director. 1594 9. Acknowledgements 1596 This document was produced by the IETF RMONMIB Working Group. 1598 The authors wish to thank the following people for their contributions 1599 to this document: 1601 Anil Singhal 1602 Frontier Software Development, Inc. 1604 Jeanne Haney 1605 Bay Networks 1607 Dan Hansen 1608 Network General Corp. 1610 Special thanks are in order to the following people for writing RMON PI 1611 macro compilers, and improving the specification of the PI macro 1612 language: 1614 David Perkins 1615 DeskTalk Systems, Inc. 1617 Skip Koppenhaver 1618 Technically Elite, Inc. 1620 10. References 1622 [AF-LANE-0021.000] 1623 LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over 1624 ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995. 1626 [AF-NM-TEST-0080.000] 1627 Network Management Sub-working Group, Test Sub-working Group, A. 1628 Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- 1629 NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997. 1631 [IEEE802.1D-1998] 1632 LAN MAN Standards Committee of the IEEE Computer Society, 1633 "Information technology -- Telecommunications and information 1634 exchange between systems -- Local and metropolitan area networks -- 1635 Common specification -- Part 3: Media Access Control (MAC) 1636 Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of 1637 Electrical and Electronics Engineers, Inc., May 1998. 1639 [IEEE802.1Q] 1640 LAN MAN Standards Committee of the IEEE Computer Society, "IEEE 1641 Standards for Local and Metropolitan Area Networks: Virtual Bridged 1642 Local Area Networks", Draft Standard P802.1Q/D11, Institute of 1643 Electrical and Electronics Engineers, Inc., July 1998. 1645 [RFC1155] 1646 Rose, M., and K. McCloghrie, "Structure and Identification of 1647 Management Information for TCP/IP-based Internets", RFC 1155, 1648 Performance Systems International, Hughes LAN Systems, May 1990. 1650 [RFC1157] 1651 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1652 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1653 International, Performance Systems International, MIT Laboratory 1654 for Computer Science, May 1990. 1656 [RFC1212] 1657 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1658 Performance Systems International, Hughes LAN Systems, March 1991. 1660 [RFC1215] 1661 M. Rose, "A Convention for Defining Traps for use with the SNMP", 1662 RFC 1215, Performance Systems International, March 1991. 1664 [RFC1483] 1665 J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 1666 5", RFC 1483, Telecom Finland, July 1993. 1668 [RFC1700] 1669 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1670 USC/Information Sciences Institute, October 1994. 1672 [RFC1901] 1673 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1674 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 1675 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1676 Inc., International Network Services, January 1996. 1678 [RFC1902] 1679 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1680 Waldbusser, "Structure of Management Information for version 2 of 1681 the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP 1682 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1683 International Network Services, January 1996. 1685 [RFC1903] 1686 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1687 Waldbusser, "Textual Conventions for version 2 of the Simple 1688 Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 1689 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1690 International Network Services, January 1996. 1692 [RFC1904] 1693 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1694 Waldbusser, "Conformance Statements for version 2 of the Simple 1695 Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, 1696 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1697 International Network Services, January 1996. 1699 [RFC1905] 1700 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1701 Waldbusser, "Protocol Operations for Version 2 of the Simple 1702 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 1703 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1704 International Network Services, January 1996. 1706 [RFC1906] 1707 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1708 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 1709 Management Protocol (SNMPv2)"", RFC 1906, SNMP Research, Inc., 1710 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1711 Network Services, January 1996. 1713 [RFC2021] 1714 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 1715 International Network Services, January 1997. 1717 [RFC2074] 1718 Bierman, A., and R. Iddon, "Remote Network Monitoring MIB Protocol 1719 Identifiers", RFC 2074, Cisco Systems, 3Com Inc., January 1997. 1721 [RFC2119] 1722 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1723 Levels", RFC 2119, Harvard University, March 1997. 1725 [RFC2233] 1726 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using 1727 SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997. 1729 [RFC2271] 1730 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1731 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1732 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1733 January 1998. 1735 [RFC2272] 1736 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1737 Processing and Dispatching for the Simple Network Management 1738 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1739 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1741 [RFC2273] 1742 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1743 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1744 Systems, January 1998. 1746 [RFC2274] 1747 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1748 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1749 2274, IBM T. J. Watson Research, January 1998. 1751 [RFC2275] 1752 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1753 Control Model (VACM) for the Simple Network Management Protocol 1754 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1755 Cisco Systems, Inc., January 1998. 1757 [RFC2570] 1758 Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 1759 Version 3 of the Internet-standard Network Management Framework", 1760 RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, 1761 Inc., Ericsson, Cisco Systems, April 1999 1763 [RFC2571] 1764 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1765 Describing SNMP Management Frameworks", RFC 2571, Cabletron 1766 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1767 1999 1769 [RFC2572] 1770 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1771 Processing and Dispatching for the Simple Network Management 1772 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 1773 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999 1775 [RFC2573] 1776 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1777 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 1778 Systems, April 1999 1780 [RFC2574] 1781 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1782 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1783 2574, IBM T. J. Watson Research, April 1999 1785 [RFC2575] 1786 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1787 Control Model (VACM) for the Simple Network Management Protocol 1788 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 1789 Cisco Systems, Inc., April 1999 1791 [RFC2578] 1792 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1793 and S. Waldbusser, "Structure of Management Information Version 2 1794 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 1795 Braunschweig, SNMP Research, First Virtual Holdings, International 1796 Network Services, April 1999 1798 [RFC2579] 1799 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1800 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 1801 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 1802 Virtual Holdings, International Network Services, April 1999 1804 [RFC2580] 1805 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1806 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 1807 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 1808 First Virtual Holdings, International Network Services, April 1999 1810 [RMONPROT_MAC] 1811 Bierman, A., Bucci, C., and R. Iddon, "Remote Network Monitoring 1812 MIB Protocol Identifier Macros", draft-ietf-rmonmib-rmonprot- 1813 mac-00.txt, Cisco Systems, 3Com, Inc., November 1998. 1815 11. IANA Considerations 1817 The protocols identified in this specification are almost entirely 1818 defined in external documents. In some rare cases, an arbitrary 1819 Protocol Identifier assignment must be made in order to support a 1820 particular protocol in the RMON-2 protocolDirTable. Protocol Identifier 1821 macros for such protocols will be defined under the 'ianaAssigned' base 1822 layer (see sections 6. and 7.2). 1824 At this time, only one protocol is defined under the ianaAssigned base 1825 layer, called 'ipxOverRaw8023' (see section 7.2). 1827 12. Security Considerations 1829 This document discusses the syntax and semantics of textual descriptions 1830 of networking protocols, not the definition of any networking behavior. 1831 As such, no security considerations are raised by this memo. 1833 13. Authors' Addresses 1835 Andy Bierman 1836 Cisco Systems, Inc. 1837 170 West Tasman Drive 1838 San Jose, CA USA 95134 1839 Phone: +1 408-527-3711 1840 Email: abierman@cisco.com 1842 Chris Bucci 1843 Cisco Systems, Inc. 1844 170 West Tasman Drive 1845 San Jose, CA USA 95134 1846 Phone: +1 408-527-5337 1847 Email: cbucci@cisco.com 1849 Robin Iddon 1850 c/o 3Com Inc. 1851 Blackfriars House 1852 40/50 Blackfrias Street 1853 Edinburgh, EH1 1NE, UK 1854 Phone: +44 131.558.3888 1855 Email: None 1857 14. Full Copyright Statement 1859 Copyright (C) The Internet Society (1999). All Rights Reserved. 1861 This document and translations of it may be copied and furnished to 1862 others, and derivative works that comment on or otherwise explain it or 1863 assist in its implementation may be prepared, copied, published and 1864 distributed, in whole or in part, without restriction of any kind, 1865 provided that the above copyright notice and this paragraph are included 1866 on all such copies and derivative works. However, this document itself 1867 may not be modified in any way, such as by removing the copyright notice 1868 or references to the Internet Society or other Internet organizations, 1869 except as needed for the purpose of developing Internet standards in 1870 which case the procedures for copyrights defined in the Internet 1871 Standards process must be followed, or as required to translate it into 1872 languages other than English. 1874 The limited permissions granted above are perpetual and will not be 1875 revoked by the Internet Society or its successors or assigns. 1877 This document and the information contained herein is provided on an "AS 1878 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1879 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1880 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1881 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1882 FITNESS FOR A PARTICULAR PURPOSE."