home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rmonmib-rmonprot-v2-00.txt < prev    next >
Text File  |  1996-11-26  |  121KB  |  4,426 lines
  1.  
  2.  
  3.  
  4.  
  5. Draft                  RMON Protocol Identifiers           November 1996
  6.  
  7.  
  8.            Remote Network Monitoring MIB Protocol Identifiers
  9.                 <draft-ietf-rmonmib-rmonprot-v2-00.txt>
  10.  
  11.                            November 25, 1996
  12.  
  13.  
  14.                               Andy Bierman
  15.                           Cisco Systems, Inc.
  16.                            abierman@cisco.com
  17.  
  18.                               Chris Bucci
  19.                       Network General Corporation
  20.                              buccic@ngc.com
  21.  
  22.                               Robin Iddon
  23.                                3Com, Inc.
  24.                        Robin_Iddon@3mail.3com.com
  25.  
  26.  
  27.  
  28.  
  29.  
  30.                           Status of this Memo
  31.  
  32. This document is an Internet-Draft.  Internet-Drafts are working
  33. documents of the Internet Engineering Task Force (IETF), its areas, and
  34. its working groups.  Note that other groups may also distribute working
  35. documents as Internet-Drafts.
  36.  
  37. Internet-Drafts are draft documents valid for a maximum of six months
  38. and may be updated, replaced, or obsoleted by other documents at any
  39. time.  It is inappropriate to use Internet- Drafts as reference material
  40. or to cite them other than as ``work in progress.''
  41.  
  42. To learn the current status of any Internet-Draft, please check the
  43. ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
  44. Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  45. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Draft                  RMON Protocol Identifiers           November 1996
  65.  
  66.  
  67. 1.  Introduction
  68.  
  69.  
  70. This memo defines an experimental portion of the Management Information
  71. Base (MIB) for use with network management protocols in the Internet
  72. community.  In particular, it describes the algorithms required to
  73. identify different protocol encapsulations managed with the Remote
  74. Network Monitoring MIB Version 2 [RMON2]. Although related to the
  75. original Remote Network Monitoring MIB [RFC1757], this document refers
  76. only to objects found in the RMON-2 MIB.
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 2]
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Draft                  RMON Protocol Identifiers           November 1996
  124.  
  125.  
  126. 2.  The SNMP Network Management Framework
  127.  
  128. The SNMP Network Management Framework presently consists of three major
  129. components.  They are:
  130.  
  131. o    the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
  132.      describing and naming objects for the purpose of management.
  133.  
  134. o    the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
  135.      objects for the Internet suite of protocols.
  136.  
  137. o    the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the
  138.      protocol for accessing managed information.
  139.  
  140.  
  141. Textual conventions are defined in RFC 1903 [RFC1903], and conformance
  142. statements are defined in RFC 1904 [RFC1904].
  143.  
  144.  
  145. The Framework permits new objects to be defined for the purpose of
  146. experimentation and evaluation.
  147.  
  148.  
  149. 2.1.  Object Definitions
  150.  
  151. Managed objects are accessed via a virtual information store, termed the
  152. Management Information Base or MIB.  Objects in the MIB are defined
  153. using the subset of Abstract Syntax Notation One (ASN.1) defined in the
  154. SMI.  In particular, each object type is named by an OBJECT IDENTIFIER,
  155. an administratively assigned name.  The object type together with an
  156. object instance serves to uniquely identify a specific instantiation of
  157. the object.  For human convenience, we often use a textual string,
  158. termed the descriptor, to refer to the object type.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Draft                  RMON Protocol Identifiers           November 1996
  183.  
  184.  
  185. 3.  Overview
  186.  
  187. The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to
  188. globally identify individual protocol encapsulations in the
  189. protocolDirTable.
  190.  
  191. This guide contains algorithms and examples of protocol identifier
  192. encapsulations for use as INDEX values in the protocolDirTable.
  193.  
  194. This document is not intended to be an authoritative reference on the
  195. protocols described herein. Refer to the Official Internet Standards
  196. document [RFC1800], the Assigned Numbers document [RFC1700], or other
  197. appropriate RFCs, IEEE documents, etc. for complete and authoritative
  198. protocol information.
  199.  
  200.  
  201.  
  202. 3.1.  Terms
  203.  
  204. Several terms are used throughout this document, as well as in the
  205. RMON-2 MIB [RMON2], that should be introduced:
  206.  
  207. layer-identifier:
  208.      An octet string fragment representing a particular protocol
  209.      encapsulation layer. A string fragment identifying a particular
  210.      protocol encapsulation layer. This string is exactly four octets,
  211.      (except for the 'vsnap' base-layer identifier, which is exactly
  212.      eight octets) encoded in network byte order. A particular protocol
  213.      encapsulation can be identified by starting with a base layer
  214.      encapsulation (see the 'Base Protocol Identifiers' section for more
  215.      detail), and following the encoding rules specified in the CHILDREN
  216.      clause and assignment section for that layer. Then repeat for each
  217.      identified layer in the encapsulation. (See section 4.3 'Evaluating
  218.      a Protocol-Identifier INDEX' for more detail.)
  219.  
  220. protocol:
  221.      A particular protocol layer, as specified by encoding rules in this
  222.      document. Usually refers to a single layer in a given
  223.      encapsulation. Note that this term is sometimes used in the RMON-2
  224.      MIB [RMON2] to name a fully-specified protocol-identifier string.
  225.      In such a case, the protocol-identifier string is named for its
  226.      upper-most layer. A named protocol may also refer to any
  227.      encapsulation of that protocol.
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 4]
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Draft                  RMON Protocol Identifiers           November 1996
  242.  
  243.  
  244. protocol-identifier string:
  245.      An octet string representing a particular protocol encapsulation,
  246.      as specified by encoding rules in this document. This string is
  247.      identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
  248.      protocol-identifier string is composed of one or more layer-
  249.      identifiers.
  250.  
  251. protocol-identifier macro:
  252.      A group of formatted text describing a particular protocol layer,
  253.      as used within the RMON-2 MIB [RMON2]. The macro serves several
  254.      purposes:
  255.  
  256.      - Name the protocol for use within the RMON-2 MIB [RMON2].
  257.      - Describe how the protocol is encoded into an octet string.
  258.      - Describe how child protocols are identified (if applicable),
  259.        and encoded into an octet string.
  260.      - Describe which protocolDirParameters are allowed for the protocol.
  261.      - Describe how the associated protocolDirType object is encoded
  262.        for the protocol.
  263.      - Provide reference(s) to authoritative documentation for the
  264.        protocol.
  265.  
  266. protocol-variant-identifier macro:
  267.      A group of formatted text describing a particular protocol layer,
  268.      as used within the RMON-2 MIB [RMON2]. This protocol is a variant
  269.      of a well known encapsulation that may be present in the
  270.      protocolDirTable. This macro is used to document the working group
  271.      assigned protocols, which are needed to identify protocols which
  272.      cannot be practically identified by examination of 'appropriate
  273.      network traffic' (e.g. the packets which carry them). All other
  274.      protocols (which can be identified by examination of appropriate
  275.      network traffic) should be documented using the protocol-identifier
  276.      macro. A protocol-variant-identifier is documented using the
  277.      protocol-variant version of the protocol-identifier macro.
  278.  
  279. protocol-parameter:
  280.      A single octet, corresponding to a specific layer-identifier in the
  281.      protocol-identifier. This octet is a bit-mask indicating special
  282.      functions or capabilities that this agent is providing for the
  283.      corresponding protocol.
  284.  
  285. protocol-parameters string:
  286.      An octet string, which contains one protocol-parameter for each
  287.      layer-identifier in the protocol-identifier.  See the section
  288.      'Mapping of the PARAMETERS Clause' for more detail.  This string is
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Draft                  RMON Protocol Identifiers           November 1996
  301.  
  302.  
  303.      identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
  304.      object.
  305.  
  306. protocolDirTable INDEX:
  307.      A protocol-identifier and protocol-parameters octet string pair
  308.      that have been converted to an INDEX value, according to the
  309.      encoding rules in in section 7.7 of RFC 1902 [RFC1902].
  310.  
  311. pseudo-protocol:
  312.      A convention or algorithm used only within this document for the
  313.      purpose of encoding protocol-identifier strings.
  314.  
  315.  
  316. 3.2.  Relationship to the Remote Network Monitoring MIB
  317.  
  318. This document is intended to identify possible string values for the
  319. OCTET STRING objects protocolDirID and protocolDirParameters.  Tables in
  320. the new Protocol Distribution, Host, and Matrix groups use a local
  321. INTEGER INDEX, in order to remain unaffected by changes in this
  322. document. Only the protocolDirTable uses the strings (protocolDirID and
  323. protocolDirParameters) described in this document.
  324.  
  325. This document is not intended to limit the protocols that may be
  326. identified for counting in the RMON-2 MIB. Many protocol encapsulations,
  327. not explicitly identified in this document, may be present in an actual
  328. implementation of the protocolDirTable. Also, implementations of the
  329. protocolDirTable may not include all the protocols identified in the
  330. example section below.
  331.  
  332. This document is intentionally separated from the MIB objects to allow
  333. frequent updates to this document without any republication of MIB
  334. objects.  Protocol Identifier macros will be collected and added to this
  335. document by the RMONMIB working group.
  336.  
  337. This document does not discuss auto-discovery and auto-population of the
  338. protocolDirTable. This functionality is not explicitly defined by the
  339. RMON standard. An agent should populate the directory with 'interesting'
  340. protocols--depending on the intended applications.
  341.  
  342.  
  343. 3.3.  Relationship to the Other MIBs
  344.  
  345. The RMON Protocol Identifiers document is intended for use with the
  346. protocolDirTable within the RMON MIB. It is not relevant to any other
  347. MIB, or intended for use with any other MIB.
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 6]
  354.  
  355.  
  356.  
  357.  
  358.  
  359. Draft                  RMON Protocol Identifiers           November 1996
  360.  
  361.  
  362. 4.  Protocol Identifier Encoding
  363.  
  364. The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and
  365. protocolDirParameters. To encode the table index, each variable-length
  366. string is converted to an OBJECT IDENTIFIER fragment, according to the
  367. encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index
  368. fragments are simply concatenated. (Refer to figures 1a - 1d below for
  369. more detail.)
  370.  
  371. The first OCTET STRING (protocolDirID) is composed of one or more 4-
  372. octet "layer-identifiers". The entire string uniquely identifies a
  373. particular protocol encapsulation tree. The second OCTET STRING,
  374. (protocolDirParameters) which contains a corresponding number of 1-octet
  375. protocol-specific parameters, one for each 4-octet layer-identifier in
  376. the first string.
  377.  
  378. A protocol layer is normally identified by a single 32-bit value.  Each
  379. layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as
  380. four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of
  381. the 32-bit value in network byte order.  If a particular protocol layer
  382. cannot be encoded into 32 bits, (except for the 'vsnap' base layer) then
  383. it must be defined as a 'wgAssigned' protocol (see below for details on
  384. working group assigned protocols).
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 7]
  413.  
  414.  
  415.  
  416.  
  417.  
  418. Draft                  RMON Protocol Identifiers           November 1996
  419.  
  420.  
  421. The following figures show the differences between the OBJECT IDENTIFIER
  422. and OCTET STRING encoding of the protocol identifier string.
  423.  
  424.                    Fig. 1a
  425.          protocolDirTable INDEX Format
  426.          -----------------------------
  427.  
  428.      +---+--------------------------+---+---------------+
  429.      | c !                          | c !  protocolDir  |
  430.      | n !  protocolDirID           | n !  Parameters   |
  431.      | t !                          | t !               |
  432.      +---+--------------------------+---+---------------+
  433.  
  434.                    Fig. 1b
  435.          protocolDirTable OCTET STRING Format
  436.          ------------------------------------
  437.  
  438.       protocolDirID
  439.      +----------------------------------------+
  440.      |                                        |
  441.      |              4 * N octets              |
  442.      |                                        |
  443.      +----------------------------------------+
  444.  
  445.      protocolDirParameters
  446.      +----------+
  447.      |          |
  448.      | N octets |
  449.      |          |
  450.      +----------+
  451.  
  452.                     Fig. 1c
  453.         protocolDirTable INDEX Format Example
  454.         -------------------------------------
  455.  
  456.      protocolDirID                   protocolDirParameters
  457.      +---+--------+--------+--------+--------+---+---+---+---+---+
  458.      | c |  proto |  proto |  proto |  proto | c |par|par|par|par|
  459.      | n |  base  |    L3  |   L4   |   L5   | n |ba-| L3| L4| L5|
  460.      | t |(+flags)|        |        |        | t |se |   |   |   |
  461.      +---+--------+--------+--------+--------+---+---+---+---+---+ subOID
  462.      | 1 | 4 or 8 |    4   |    4   |    4   | 1 |1/2| 1 | 1 | 1 | count
  463.  
  464.      where N is the number of protocol-layer-identifiers required
  465.      for the entire encapsulation of the named protocol. Note that
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 8]
  472.  
  473.  
  474.  
  475.  
  476.  
  477. Draft                  RMON Protocol Identifiers           November 1996
  478.  
  479.  
  480.      the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
  481.      All other protocol layers are either encoded into 4 sub-identifiers
  482.      or encoded as a 'wgAssigned' protocol.
  483.  
  484.                     Fig. 1d
  485.        protocolDirTable OCTET STRING Format Example
  486.        --------------------------------------------
  487.  
  488.      protocolDirID
  489.      +--------+--------+--------+--------+
  490.      |  proto |  proto |  proto |  proto |
  491.      |   base |    L3  |   L4   |   L5   |
  492.      |        |        |        |        |
  493.      +--------+--------+--------+--------+ octet
  494.      | 4 or 8 |    4   |    4   |    4   | count
  495.  
  496.  
  497.      protocolDirParameters
  498.      +---+---+---+---+
  499.      |par|par|par|par|
  500.      |ba-| L3| L4| L5|
  501.      |se |   |   |   |
  502.      +---+---+---+---+ octet
  503.      |1/2| 1 | 1 | 1 | count
  504.  
  505.      where N is the number of protocol-layer-identifiers required
  506.      for the entire encapsulation of the named protocol. Note that
  507.      the 'vsnap' base layer identifier is encoded into 8
  508.      protocolDirID sub-identifiers and 2 protocolDirParameters
  509.      sub-identifiers.
  510.  
  511.  
  512. Although this example indicates four encapsulated protocols, in
  513. practice, any non-zero number of layer-identifiers may be present,
  514. theoretically limited only by OBJECT IDENTIFIER length restrictions, as
  515. specified in section 3.5 of RFC 1902 [RFC1902].
  516.  
  517. Note that these two strings would not be concatenated together if ever
  518. returned in a GetResponse PDU, since they are different MIB objects.
  519. However, protocolDirID and protocolDirParameters are not currently
  520. readable MIB objects.
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530. Bierman/Bucci/Iddon        Expires May, 1997                    [Page 9]
  531.  
  532.  
  533.  
  534.  
  535.  
  536. Draft                  RMON Protocol Identifiers           November 1996
  537.  
  538.  
  539. 4.1.  ProtocolDirTable INDEX Format Examples
  540.  
  541.  -- HTTP; fragments counted from IP and above
  542.  ether2.ip.tcp.www-http =
  543.     16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
  544.  
  545.  -- SNMP over UDP/IP over SNAP
  546.  snap.ip.udp.snmp =
  547.     16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
  548.  
  549.  -- SNMP over IPX over SNAP
  550.  snap.ipx.snmp =
  551.     12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
  552.  
  553.  -- SNMP over IPX over raw8023
  554.  -- wgAssigned(ipxOverRaw8023(1)).snmp =
  555.     12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
  556.  
  557.  -- IPX over LLC
  558.  llc.ipx =
  559.     8.0.0.0.2.0.224.224.3.2.0.0
  560.  
  561.  -- SNMP over UDP/IP over any link layer
  562.  -- wildcard-ether2.ip.udp.snmp
  563.     16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
  564.  
  565.  -- IP over any link layer; base encoding is IP over ether2
  566.  -- wildcard-ether2.ip
  567.     8.1.0.0.1.0.0.8.0.2.0.0
  568.  
  569. -- AppleTalk Phase 2 over ether2
  570. -- ether2.atalk
  571.    8.0.0.0.1.0.0.128.155.2.0.0
  572.  
  573. -- AppleTalk Phase 2 over vsnap
  574. -- vsnap(apple).atalk
  575.    12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
  576.  
  577.  
  578. 4.2.  Protocol Identifier Macro Format
  579.  
  580. The following example is meant to introduce the protocol-identifier
  581. macro. (The syntax is not quite ASN.1.) This macro is used to represent
  582. both protocols and protocol-variants.
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 10]
  590.  
  591.  
  592.  
  593.  
  594.  
  595. Draft                  RMON Protocol Identifiers           November 1996
  596.  
  597.  
  598. If the 'VariantOfPart' component of the macro is present, then the macro
  599. represents a protocol-variant instead of a protocol.  A protocol-
  600. variant-identifier is used only for working group assigned protocols,
  601. enumerated under the 'wgAssigned' base-layer.
  602.  
  603.  
  604.      RMON-PROTOCOL-IDENTIFIER MACRO ::=
  605.      BEGIN
  606.              PIMacroName "PROTOCOL-IDENTIFIER"
  607.                      VariantOfPart
  608.                      "PARAMETERS"   ParamPart
  609.                      "ATTRIBUTES"   AttrPart
  610.                      "DESCRIPTION"  Text
  611.                      ChildDescrPart
  612.                      AddrDescrPart
  613.                      DecodeDescrPart
  614.                      ReferPart
  615.              "::=" "{" EncapsPart "}"
  616.  
  617.              PIMacroName ::=
  618.                  identifier
  619.  
  620.              VariantOfPart ::=
  621.                  "VARIANT-OF" identifier | empty
  622.  
  623.              ParamPart ::=
  624.                  "{" ParamList "}"
  625.  
  626.              ParamList ::=
  627.                  Params | empty
  628.  
  629.              Params ::=
  630.                  Param | Params "," Param
  631.  
  632.              Param ::=
  633.                  identifier "(" nonNegativeNumber ")"
  634.  
  635.              AttrPart ::=
  636.                  "{" AttrList "}"
  637.  
  638.              AttrList ::=
  639.                  Attrs | empty
  640.  
  641.              Attrs ::=
  642.                  Attr | Attrs "," Attr
  643.  
  644.  
  645.  
  646.  
  647.  
  648. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 11]
  649.  
  650.  
  651.  
  652.  
  653.  
  654. Draft                  RMON Protocol Identifiers           November 1996
  655.  
  656.  
  657.              Attr ::=
  658.                  identifier "(" nonNegativeNumber ")"
  659.  
  660.              ChildDescrPart ::=
  661.                  "CHILDREN" Text | empty
  662.  
  663.              AddrDescrPart ::=
  664.                  "ADDRESS-FORMAT" Text | empty
  665.  
  666.              DecodeDescrPart ::=
  667.                  "DECODING" Text | empty
  668.  
  669.              ReferPart ::=
  670.                  "REFERENCE" Text | empty
  671.  
  672.              EncapsPart ::=
  673.                  "{" Encaps "}"
  674.  
  675.              Encaps ::=
  676.                  Encap | Encaps "," Encap
  677.  
  678.              Encap ::=
  679.                  BaseEncap | NormalEncap | VsnapEncap | WgEncap
  680.  
  681.              BaseEncap ::=
  682.                  nonNegativeNumber
  683.  
  684.              NormalEncap ::=
  685.                  identifier nonNegativeNumber
  686.  
  687.              VsnapEncap ::=
  688.                  identifier "(" nonNegativeNumber ")" nonNegativeNumber
  689.  
  690.              WgEncap ::=
  691.                  "wgAssigned" nonNegativeNumber
  692.                  | "wgAssigned" identifier
  693.                  | "wgAssigned" identifier "(" nonNegativeNumber ")"
  694.  
  695.              Text ::=
  696.                  """" string """"
  697.      END
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 12]
  708.  
  709.  
  710.  
  711.  
  712.  
  713. Draft                  RMON Protocol Identifiers           November 1996
  714.  
  715.  
  716. 4.2.1.  Mapping of the Protocol Name
  717.  
  718. The 'PIMacroName' value should be a lower-case ASCII string, and contain
  719. the name or acronym identifying the protocol.  NMS applications may
  720. treat protocol names as case-insensitive strings, and agent
  721. implementations must make sure the protocolDirTable does not contain any
  722. instances of the protocolDirDescr object which differ only in the case
  723. of one of more letters (if the identifiers are intended to represent
  724. different protocols).
  725.  
  726. It is possible that different encapsulations of the same protocol (which
  727. are represented by different entries in the protocolDirTable) will be
  728. assigned the same protocol name.
  729.  
  730. A protocol name should match the "most well-known" name or acronym for
  731. the indicated protocol.  For example, the document indicated by the URL:
  732.  
  733.     ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
  734.  
  735. defines IP Protocol field values, so protocol-identifier macros for
  736. children of IP should be given names consistent with the protocol names
  737. found in this authoritative document.
  738.  
  739.  
  740.  
  741. 4.2.2.  Mapping of the VARIANT-OF Clause
  742.  
  743. This clause is present for working group assigned protocols only.  It
  744. identifies the protocol-identifier macro that most closely represents
  745. this 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'.
  749.  
  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.
  754.  
  755. Since the PARAMETERS and ATTRIBUTES clauses must be present in a
  756. protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
  757. "PARAMETERS {}") must be present in a protocol-variant-identifier macro,
  758. and the 'ParamPart' and 'AttrPart' found in the reference protocol-
  759. identifier macro examined instead.
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 13]
  767.  
  768.  
  769.  
  770.  
  771.  
  772. Draft                  RMON Protocol Identifiers           November 1996
  773.  
  774.  
  775. Note that if a 'wgAssigned' protocol is defined that is not a variant of
  776. any other documented protocol, then the protocol-identifier macro should
  777. be used instead of the protocol-variant-identifier version of the macro.
  778.  
  779.  
  780.  
  781. 4.2.3.  Mapping of the PARAMETERS Clause
  782.  
  783. The protocolDirParameters object provides an NMS the ability to turn on
  784. and off expensive probe resources. An agent may support a given
  785. parameter all the time, not at all, or subject to current resource load.
  786.  
  787. The PARAMETERS clause is a list of bit definitions which can be directly
  788. encoded into the associated ProtocolDirParameters octet in network byte
  789. order. Zero or more bit definitions may be present. Only bits 0-7 are
  790. valid encoding values. This clause defines the entire BIT set allowed
  791. for a given protocol. A conforming agent may choose to implement a
  792. subset of zero or more of these PARAMETERS.
  793.  
  794. By convention, the following common bit definitions are used by
  795. different protocols.  These bit positions must not be used for other
  796. parameters. They should be reserved if not used by a given protocol.
  797. Bits are encoded in network-byte order.
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 14]
  826.  
  827.  
  828.  
  829.  
  830.  
  831. Draft                  RMON Protocol Identifiers           November 1996
  832.  
  833.  
  834.          Table 3.1  Reserved PARAMETERS Bits
  835.          ------------------------------------
  836.  
  837.      Bit Name              Description
  838.      ---------------------------------------------------------------------
  839.      0   countsFragments   higher-layer protocols encapsulated within
  840.                            this protocol will be counted correctly even
  841.                            if this protocol fragments the upper layers
  842.                            into multiple packets.
  843.      1   tracksSessions    correctly attributes all packets of a protocol
  844.                            which starts sessions on well known ports or
  845.                            sockets and then transfers them to dynamically
  846.                            assigned ports or sockets thereafter (e.g. TFTP).
  847.  
  848.  
  849. The PARAMETERS clause must be present in all protocol-identifier macro
  850. declarations, but may be equal to zero (empty). Note that an NMS must
  851. determine if a given PARAMETER bit is supported by attempting to create
  852. the desired protocolDirEntry The associated ATTRIBUTE bits for
  853. 'countsFragments' and 'tracksSessions' do not exist.
  854.  
  855.  
  856. 4.2.3.1.  Mapping of the 'countsFragments(0)' BIT
  857.  
  858. This bit indicates whether the probe is correctly attributing all
  859. fragmented packets of the specified protocol, even if individual frames
  860. carrying this protocol cannot be identified as such.  Note that the
  861. probe is not required to actually present any re-assembled datagrams
  862. (for address-analysis, filtering, or any other purpose) to the NMS.
  863.  
  864. This bit may only be set in a protocolDirParameters octet which
  865. corresponds to a protocol that supports fragmentation and reassembly in
  866. some form. Note that TCP packets are not considered 'fragmented-streams'
  867. and so TCP is not eligible.
  868.  
  869. This bit may be set in at most one protocolDirParameters octet within a
  870. protocolDirTable INDEX.
  871.  
  872.  
  873.  
  874. 4.2.3.2.  Mapping of the 'tracksSessions(1)' BIT
  875.  
  876. The 'tracksSessions(1)' bit indicates whether frames which are part of
  877. remapped-sessions (e.g. TFTP download sessions) are correctly counted by
  878. the probe. For such a protocol, the probe must usually analyze all
  879.  
  880.  
  881.  
  882.  
  883.  
  884. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 15]
  885.  
  886.  
  887.  
  888.  
  889.  
  890. Draft                  RMON Protocol Identifiers           November 1996
  891.  
  892.  
  893. packets received on the indicated interface, and maintain some state
  894. information, (e.g. the remapped UDP port number for TFTP).
  895.  
  896. The semantics of the 'tracksSessions' parameter are independent of the
  897. other protocolDirParameters definitions, so this parameter may be
  898. combined with any other legal parameter configurations.
  899.  
  900.  
  901.  
  902. 4.2.4.  Mapping of the ATTRIBUTES Clause
  903.  
  904. The protocolDirType object provides an NMS with an indication of a
  905. probe's capabilities for decoding a given protocol, or the general
  906. attributes of the particular protocol.
  907.  
  908. The ATTRIBUTES clause is a list of bit definitions which are encoded
  909. into the associated instance of ProtocolDirType. The BIT definitions are
  910. specified in the SYNTAX clause of the protocolDirType MIB object.
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 16]
  944.  
  945.  
  946.  
  947.  
  948.  
  949. Draft                  RMON Protocol Identifiers           November 1996
  950.  
  951.  
  952.          Table 3.2  Reserved ATTRIBUTES Bits
  953.          ------------------------------------
  954.  
  955.      Bit Name              Description
  956.      ---------------------------------------------------------------------
  957.      0  hasChildren        indicates that there may be children of
  958.                            this protocol defined in the protocolDirTable
  959.                            (by either the agent or the manager).
  960.      1  addressRecognitionCapable
  961.                            indicates that this protocol can be used
  962.                            to generate host and matrix table entries.
  963.  
  964.  
  965. The ATTRIBUTES clause must be present in all protocol-identifier macro
  966. declarations, but may be empty.
  967.  
  968.  
  969. 4.2.5.  Mapping of the DESCRIPTION Clause
  970.  
  971. The DESCRIPTION clause provides a textual description of the protocol
  972. identified by this macro.  Notice that it should not contain details
  973. about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
  974. REFERENCE clauses.
  975.  
  976. The DESCRIPTION clause must be present in all protocol-identifier macro
  977. declarations.
  978.  
  979.  
  980. 4.2.6.  Mapping of the CHILDREN Clause
  981.  
  982. The CHILDREN clause provides a description of child protocols for
  983. protocols which support them. It has three sub-sections:
  984.  
  985.   -  Details on the field(s)/value(s) used to select the child protocol,
  986.      and how that selection process is performed
  987.  
  988.   -  Details on how the value(s) are encoded in the protocol identifier
  989.      octet string
  990.  
  991.   -  Details on how child protocols are named with respect to their
  992.      parent protocol label(s)
  993.  
  994. The CHILDREN clause must be present in all protocol-identifier macro
  995. declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES
  996. clause.
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 17]
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008. Draft                  RMON Protocol Identifiers           November 1996
  1009.  
  1010.  
  1011. 4.2.7.  Mapping of the ADDRESS-FORMAT Clause
  1012.  
  1013. The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
  1014. format(s) used when encoding addresses.
  1015.  
  1016. This clause must be present in all protocol-identifier macro
  1017. declarations in which the 'addressRecognitionCapable(1)' BIT is set in
  1018. the ATTRIBUTES clause.
  1019.  
  1020. 4.2.8.  Mapping of the DECODING Clause
  1021.  
  1022. The DECODING clause provides a description of the decoding procedure for
  1023. the specified protocol. It contains useful decoding hints for the
  1024. implementor, but should not over-replicate information in documents
  1025. cited in the REFERENCE clause.  It might contain a complete description
  1026. of any decoding information required.
  1027.  
  1028. For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
  1029. offset and type information for the field(s) used for child selection as
  1030. well as information on determining the start of the child protocol.
  1031.  
  1032. For 'addressRecognitionCapable' protocols this includes offset and type
  1033. information for the field(s) used to generate addresses.
  1034.  
  1035. The DECODING clause is optional, and may be omitted if the REFERENCE
  1036. clause contains pointers to decoding information for the specified
  1037. protocol.
  1038.  
  1039.  
  1040. 4.2.9.  Mapping of the REFERENCE Clause
  1041.  
  1042. If a publicly available reference document exists for this protocol it
  1043. should be listed here.  Typically this will be a URL if possible; if not
  1044. then it will be the name and address of the controlling body.
  1045.  
  1046. The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
  1047. amount of information which may currently be obtained from an
  1048. 'authoritative' document, such as the Assigned Numbers document
  1049. [RFC1700]. Any duplication or paraphrasing of information should be
  1050. brief and consistent with the authoritative document.
  1051.  
  1052. The REFERENCE clause is optional, but should be implemented if an
  1053. authoritative reference exists for the protocol (especially for standard
  1054. protocols).
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 18]
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067. Draft                  RMON Protocol Identifiers           November 1996
  1068.  
  1069.  
  1070. 4.3.  Evaluating a Protocol-Identifier INDEX
  1071.  
  1072. The following evaluation is done after protocolDirTable INDEX value has
  1073. been converted into two OCTET STRINGs according to the INDEX encoding
  1074. rules specified in the SMI [RFC1902].
  1075.  
  1076. Protocol-identifiers are evaluated left to right, starting with the
  1077. protocolDirID, which length should be evenly divisible by four. The
  1078. protocolDirParameters length should be exactly one quarter of the
  1079. protocolDirID string length.
  1080.  
  1081. Protocol-identifier parsing starts with the base layer identifier, which
  1082. must be present, and continues for one or more upper layer identifiers,
  1083. until all OCTETs of the protocolDirID have been used. Layers may not be
  1084. skipped, so identifiers such as 'SNMP over IP' or 'TCP over anylink' can
  1085. not exist.
  1086.  
  1087. The base-layer-identifier also contains a 'special function identifier'
  1088. which may apply to the rest of the protocol identifier.
  1089.  
  1090. Wild-carding at the base layer within a protocol encapsulation is the
  1091. only supported special function at this time. Refer to the 'Base
  1092. Protocol Identifiers' section for wildcard encoding rules.
  1093.  
  1094. After the protocol-tree identified in protocolDirID has been parsed,
  1095. each parameter bit-mask (one octet for each 4-octet layer-identifier) is
  1096. evaluated, and applied to the corresponding protocol layer.
  1097.  
  1098. A protocol-identifier label may map to more than one value.  For
  1099. instance, 'ip' maps to 5 distinct values, one for each supported
  1100. encapsulation.  (see the 'IP' section under 'L3 Protocol Identifiers'),
  1101.  
  1102. It is important to note that these macros are conceptually expanded at
  1103. implementation time, not at run time.
  1104.  
  1105. If all the macros are expanded completely by substituting all possible
  1106. values of each label for each child protocol, a list of all possible
  1107. protocol-identifiers is produced.  So 'ip' would result in 5 distinct
  1108. protocol-identifiers.  Likewise each child of 'ip' would map to at least
  1109. 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2,
  1110. ip over LLC, etc.).
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 19]
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126. Draft                  RMON Protocol Identifiers           November 1996
  1127.  
  1128.  
  1129. 5.  Protocol Identifier Macros
  1130.  
  1131. The following PROTOCOL IDENTIFIER macros can be used to construct
  1132. protocolDirID and protocolDirParameters strings.
  1133.  
  1134. The sections defining protocol examples are intended to grow over
  1135. subsequent releases. Minimal protocol support is included at this time.
  1136. (Refer to section 3.2 for details on the protocol macro update
  1137. procedure.)
  1138.  
  1139. An identifier is encoded by constructing the base-identifier, then
  1140. adding one layer-identifier for each encapsulated protocol.
  1141.  
  1142.  
  1143. 5.1.  Base Identifier Encoding
  1144.  
  1145. The first layer encapsulation is called the base identifier and it
  1146. contains optional protocol-function information and the base layer (e.g.
  1147. MAC layer) enumeration value used in this protocol identifier.
  1148.  
  1149. The base identifier is encoded as four octets as shown in figure 2.
  1150.  
  1151.           Fig. 2
  1152.      base-identifier format
  1153.      +---+---+---+---+
  1154.      |   |   |   |   |
  1155.      | f |op1|op2| m |
  1156.      |   |   |   |   |
  1157.      +---+---+---+---+ octet
  1158.      | 1 | 1 | 1 | 1 | count
  1159.  
  1160. The first octet ('f') is the special function code, found in table 4.1.
  1161. The next two octets ('op1' and 'op2') are operands for the indicated
  1162. function. If not used, an operand must be set to zero.  The last octet,
  1163. 'm', is the enumerated value for a particular base layer encapsulation,
  1164. found in table 4.2.  All four octets are encoded in network-byte-order.
  1165.  
  1166.  
  1167.  
  1168. 5.1.1.  Protocol Identifier Functions
  1169.  
  1170. The base layer identifier contains information about any special
  1171. functions to perform during collections of this protocol, as well as the
  1172. base layer encapsulation identifier.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 20]
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185. Draft                  RMON Protocol Identifiers           November 1996
  1186.  
  1187.  
  1188. The first three octets of the identifier contain the function code and
  1189. two optional operands. The fourth octet contains the particular base
  1190. layer encapsulation used in this protocol (fig. 2).
  1191.  
  1192.      Table 4.1  Assigned Protocol Identifier Functions
  1193.      -------------------------------------------------
  1194.  
  1195.            Function     ID    Param1               Param2
  1196.            ----------------------------------------------------
  1197.            none          0    not used (0)         not used (0)
  1198.            wildcard      1    not used (0)         not used (0)
  1199.  
  1200.  
  1201.  
  1202. 5.1.1.1.  Function 0: No-op
  1203.  
  1204. If the function ID field (1st octet) is equal to zero, the the 'op1' and
  1205. 'op2' fields (2nd and 3rd octets) must also be equal to zero. This
  1206. special value indicates that no functions are applied to the protocol
  1207. identifier encoded in the remaining octets. The identifier represents a
  1208. normal protocol encapsulation.
  1209.  
  1210.  
  1211. 5.1.1.2.  Function 1: Protocol Wildcard Function
  1212.  
  1213. The wildcard function (function-ID = 1), is used to aggregate counters,
  1214. by using a single protocol value to indicate potentially many base layer
  1215. encapsulations of a particular network layer protocol. A
  1216. protocolDirEntry of this type will match any base-layer encapsulation of
  1217. the same protocol.
  1218.  
  1219. The 'op1' field (2nd octet) is not used and must be set to zero.
  1220.  
  1221. The 'op2' field (3rd octet) is not used and must be set to zero.
  1222.  
  1223. Each wildcard protocol identifier must be defined in terms of a 'base
  1224. encapsulation'. This should be as 'standard' as possible for
  1225. interoperability purposes. If an encapsulation over 'ether2' is
  1226. permitted, than this should be used as the base encapsulation.
  1227.  
  1228. The agent may also be requested to count some or all of the individual
  1229. encapsulations for the same protocols, in addition to wildcard counting.
  1230. Note that the RMON-2 MIB [RMON2] does not require that agents maintain
  1231. counters for multiple encapsulations of the same protocol.  It is an
  1232. implementation-specific matter as to how an agent determines which
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 21]
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244. Draft                  RMON Protocol Identifiers           November 1996
  1245.  
  1246.  
  1247. protocol combinations to allow in the protocolDirTable at any given
  1248. time.
  1249.  
  1250.  
  1251.  
  1252. 5.2.  Base Layer Protocol Identifiers
  1253.  
  1254. The base layer is mandatory, and defines the base encapsulation of the
  1255. packet and any special functions for this identifier.
  1256.  
  1257. There are no suggested protocolDirParameters bits for the base layer.
  1258.  
  1259. The suggested ProtocolDirDescr field for the base layer is given by the
  1260. corresponding "Name" field in the table 4.1 below. However,
  1261. implementations are only required to use the appropriate integer
  1262. identifier values.
  1263.  
  1264. For most base layer protocols, the protocolDirType field should contain
  1265. bits set for  the 'hasChildren(0)' and 'addressRecognitionCapable(1)'
  1266. attributes.  However, the special 'wgAssigned' base layer should have no
  1267. parameter or attribute bits set.
  1268.  
  1269. By design, only 255 different base layer encapsulations are supported.
  1270. There are five base encapsulation values defined at this time. New base
  1271. encapsulations (e.g. for new media types) are expected to be added over
  1272. time.
  1273.  
  1274.  
  1275.      Table 4.2  Base Layer Encoding Values
  1276.      --------------------------------------
  1277.  
  1278.            Name          ID
  1279.            ------------------
  1280.            ether2        1
  1281.            llc           2
  1282.            snap          3
  1283.            vsnap         4
  1284.            wgAssigned    5
  1285.  
  1286.  
  1287. 5.2.1.  Ether2 Encapsulation
  1288.  
  1289. ether2 PROTOCOL-IDENTIFIER
  1290.     PARAMETERS { }
  1291.     ATTRIBUTES {
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 22]
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303. Draft                  RMON Protocol Identifiers           November 1996
  1304.  
  1305.  
  1306.         hasChildren(0)
  1307.     }
  1308.     DESCRIPTION
  1309.        "DIX Ethernet, also called Ethernet-II."
  1310.     CHILDREN
  1311.        "The Ethernet-II type field is used to select child protocols.
  1312.        This is a 16-bit field.  Child protocols are deemed to start at
  1313.        the first octet after this type field.
  1314.  
  1315.        Children of this protocol are encoded as [ 0.0.0.1 ], the
  1316.        protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
  1317.        'a' and 'b' are the network byte order encodings of the MSB and
  1318.        LSB of the Ethernet-II type value.
  1319.  
  1320.        For example, a protocolDirID-fragment value of:
  1321.           0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
  1322.  
  1323.        Children of are named as 'ether2' followed by the type field
  1324.        value in hexadecimal.  The above example would be declared as:
  1325.           ether2 0x0800"
  1326.     ADDRESS-FORMAT
  1327.        "Ethernet addresses are 6 octets in network order."
  1328.     DECODING
  1329.        "Only type values greater than or equal to 1500 decimal indicate
  1330.        Ethernet-II frames; lower values indicate 802.3 encapsulation
  1331.        (see below)."
  1332.     REFERENCE
  1333.        "A Standard for the Transmission of IP Datagrams over Ethernet
  1334.        Networks; RFC 894 [RFC894].
  1335.  
  1336.        The authoritative list of Ether Type values is identified by the
  1337.        URL:
  1338.  
  1339.           ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
  1340.     ::= { 1 }
  1341.  
  1342. 5.2.2.  LLC Encapsulation
  1343.  
  1344. llc PROTOCOL-IDENTIFIER
  1345.     PARAMETERS { }
  1346.     ATTRIBUTES {
  1347.         hasChildren(0)
  1348.     }
  1349.     DESCRIPTION
  1350.        "The LLC (802.2) protocol."
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 23]
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362. Draft                  RMON Protocol Identifiers           November 1996
  1363.  
  1364.  
  1365.     CHILDREN
  1366.        "The LLC SSAP and DSAP (Source/Dest Service Access Points) are
  1367.        used to select child protocols.  Each of these is one octet long,
  1368.        although the least significant bit is a control bit and should be
  1369.        masked out in most situations.  Typically SSAP and DSAP (once
  1370.        masked) are the same for a given protocol - each end implicitly
  1371.        knows whether it is the server or client in a client/server
  1372.        protocol.  This is only a convention, however, and it is possible
  1373.        for them to be different.  The SSAP is matched against child
  1374.        protocols first.  If none is found then the DSAP is matched
  1375.        instead.  The child protocol is deemed to start at the first
  1376.        octet after the LLC control field(s).
  1377.  
  1378.        Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
  1379.        identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
  1380.        the SAP value which maps to the child protocol.  For example, a
  1381.        protocolDirID-fragment value of:
  1382.           0.0.0.2.0.0.0.240
  1383.  
  1384.        defines NetBios over LLC.
  1385.  
  1386.        Children are named as 'llc' followed by the SAP value in
  1387.        hexadecimal.  So the above example would have been named:
  1388.           llc 0xf0"
  1389.     ADDRESS-FORMAT
  1390.        "The address consists of 6 octets of MAC address in network
  1391.        order.  Source routing bits should be stripped out of the address
  1392.        if present."
  1393.     DECODING
  1394.        "Notice that LLC has a variable length protocol header; there are
  1395.        always three octets (DSAP, SSAP, control).  Depending on the
  1396.        value of the control bits in the DSAP, SSAP and control fields
  1397.        there may be an additional octet of control information.
  1398.  
  1399.        LLC can be present on several different media.  For 802.3 and
  1400.        802.5 its presence is mandated (but see ether2 and raw802.3
  1401.        encapsulations).  For 802.5 there is no other link layer
  1402.        protocol.
  1403.  
  1404.        Notice also that the raw802.3 link layer protocol may take
  1405.        precedence over this one in a protocol specific manner such that
  1406.        it may not be possible to utilize all LSAP values if raw802.3 is
  1407.        also present."
  1408.     REFERENCE
  1409.        "The authoritative list of LLC LSAP values is controlled by the
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 24]
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421. Draft                  RMON Protocol Identifiers           November 1996
  1422.  
  1423.  
  1424.        IEEE Registration Authority:
  1425.        IEEE Registration Authority
  1426.           c/o Iris Ringel
  1427.           IEEE Standards Dept
  1428.           445 Hoes Lane, P.O. Box 1331
  1429.           Piscataway, NJ 08855-1331
  1430.           Phone +1 908 562 3813
  1431.           Fax: +1 908 562 1571"
  1432.     ::= { 2 }
  1433.  
  1434. 5.2.3.  SNAP over LLC (OUI=000) Encapsulation
  1435.  
  1436. snap PROTOCOL-IDENTIFIER
  1437.     PARAMETERS { }
  1438.     ATTRIBUTES {
  1439.         hasChildren(0)
  1440.     }
  1441.     DESCRIPTION
  1442.        "The Sub-Network Access Protocol (SNAP) is layered on top of LLC
  1443.        protocol, allowing Ethernet-II protocols to be run over a media
  1444.        restricted to LLC."
  1445.     CHILDREN
  1446.        "Children of 'snap' are identified by Ethernet-II type values;
  1447.        the SNAP PID (Protocol Identifier) field is used to select the
  1448.        appropriate child.  The entire SNAP protocol header is consumed;
  1449.        the child protocol is assumed to start at the next octet after
  1450.        the PID.
  1451.  
  1452.        Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
  1453.        identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
  1454.        are the MSB and LSB of the Ethernet-II type value.  For example,
  1455.        a protocolDirID-fragment value of:
  1456.           0.0.0.3.0.0.8.0
  1457.  
  1458.        defines the IP/SNAP protocol.
  1459.  
  1460.        Children of this protocol are named 'snap' followed by the
  1461.        Ethernet-II type value in hexadecimal.  The above example would
  1462.        be named:
  1463.  
  1464.           snap 0x0800"
  1465.     ADDRESS-FORMAT
  1466.          "The address format for SNAP is the same as that for LLC"
  1467.     DECODING
  1468.        "SNAP is only present over LLC.  Both SSAP and DSAP will be 0xAA
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 25]
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480. Draft                  RMON Protocol Identifiers           November 1996
  1481.  
  1482.  
  1483.        and a single control octet will be present.  There are then three
  1484.        octets of OUI and two octets of PID.  For this encapsulation the
  1485.        OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
  1486.     REFERENCE
  1487.        "SNAP Identifier values are assigned by the IEEE Standards
  1488.        Office.  The address is:
  1489.                IEEE Registration Authority
  1490.                c/o Iris Ringel
  1491.                IEEE Standards Dept
  1492.                445 Hoes Lane, P.O. Box 1331
  1493.                Piscataway, NJ 08855-1331
  1494.                Phone +1 908 562 3813
  1495.                Fax: +1 908 562 1571"
  1496.     ::= { 3 }
  1497.  
  1498. 5.2.4.  SNAP over LLC (OUI != 000) Encapsulation
  1499.  
  1500. vsnap PROTOCOL-IDENTIFIER
  1501.     PARAMETERS { }
  1502.     ATTRIBUTES {
  1503.         hasChildren(0)
  1504.     }
  1505.     DESCRIPTION
  1506.        "This pseudo-protocol handles all SNAP packets which do not have
  1507.        a zero OUI.  See 'snap' above for details of those that do."
  1508.     CHILDREN
  1509.        "Children of 'vsnap' are selected by the 3 octet OUI; the PID is
  1510.        not parsed; child protocols are deemed to start with the first
  1511.        octet of the SNAP PID field, and continue to the end of the
  1512.        packet.
  1513.  
  1514.        Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
  1515.        identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
  1516.        'a', 'b' and 'c' are the 3 octets of the OUI field in network
  1517.        byte order. This is in turn followed by the 16-bit EtherType
  1518.        value, where the 'd' and 'e' represent the MSB and LSB of the
  1519.        EtherType, respectively.
  1520.  
  1521.        For example, a protocolDirID-fragment value of:
  1522.          0.0.0.4.0.8.0.7.0.0.128.155
  1523.  
  1524.        defines the AppleTalk Phase 2 protocol over vsnap.
  1525.  
  1526.        Note that two protocolDirParameters octets must be present in
  1527.        protocolDirTable INDEX values for 'vsnap' protocols.  The first
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 26]
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539. Draft                  RMON Protocol Identifiers           November 1996
  1540.  
  1541.  
  1542.        protocolDirParameters octet defines the actual parameters. The
  1543.        second protocolDirParameters octet is not used and must be set to
  1544.        zero.
  1545.  
  1546.        Children are named as 'vsnap(<OUI>) <ethertype>', where the
  1547.        '<OUI>' field is represented as 3 octets in hexadecimal notation
  1548.        or the ASCII string associated with the OUI value. The
  1549.        <ethertype> field is represented by the 2 byte EtherType value in
  1550.        hexadecimal notation. So the above example would be named:
  1551.  
  1552.          'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
  1553.     ADDRESS-FORMAT
  1554.        "The LLC address format is inherited by 'vsnap'.  See the 'llc'
  1555.        protocol identifier for more details."
  1556.     DECODING
  1557.        "Same as for 'snap' except the OUI is non-zero."
  1558.     REFERENCE
  1559.        "SNAP Identifier values are assigned by the IEEE Standards
  1560.        Office.  The address is:
  1561.                IEEE Registration Authority
  1562.                c/o Iris Ringel
  1563.                IEEE Standards Dept
  1564.                445 Hoes Lane, P.O. Box 1331
  1565.                Piscataway, NJ 08855-1331
  1566.                Phone +1 908 562 3813
  1567.                Fax: +1 908 562 1571"
  1568.     ::= { 4 }
  1569.  
  1570. 5.2.5.  Working Group Assigned Protocols
  1571.  
  1572. wgAssigned PROTOCOL-IDENTIFIER
  1573.     PARAMETERS { }
  1574.     ATTRIBUTES { }
  1575.     DESCRIPTION
  1576.        "This branch contains protocols which do not conform easily to
  1577.        the hierarchical format utilized in the other link layer
  1578.        branches.  Usually, such a protocol 'almost' conforms to a
  1579.        particular 'well-known' identifier format, but additional
  1580.        criteria are used (e.g. configuration-based), making protocol
  1581.        identification difficult or impossible by examination of
  1582.        appropriate network traffic (preventing the any 'well-known'
  1583.        protocol-identifier macro from being used).
  1584.  
  1585.        Sometimes well-known protocols are simply remapped to a different
  1586.        port number by one or more venders (e.g. SNMP). These protocols
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 27]
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598. Draft                  RMON Protocol Identifiers           November 1996
  1599.  
  1600.  
  1601.        can be identified with the 'user-extensibility' feature of the
  1602.        protocolDirTable, and do not need special working group
  1603.        assignments.
  1604.  
  1605.        A centrally located list of these enumerated protocols must be
  1606.        maintained by the RMON working group to insure interoperability.
  1607.        (See section 3.2 for details on the document update procedure.)
  1608.        Support for new link-layers will be added explicitly, and only
  1609.        protocols which cannot possibly be represented in a better way
  1610.        will be considered as 'wgEnumerated' protocols.
  1611.  
  1612.        Working group protocols are identified by the base-layer-selector
  1613.        value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the
  1614.        integer value corresponding to the particular WG protocol.
  1615.  
  1616.        Do not create children of this protocol unless you are sure that
  1617.        they cannot be handled by the more conventional link layers
  1618.        above."
  1619.     CHILDREN
  1620.        "Children of this protocol are identified by implementation-
  1621.        specific means, described (as best as possible) in the 'DECODING'
  1622.        clause within the protocol-variant-identifier macro for each
  1623.        enumerated protocol.
  1624.  
  1625.        For example, a protocolDirID-fragment value of:
  1626.           0.0.0.5.0.0.0.1
  1627.  
  1628.        defines the IPX protocol encapsulated directly in 802.3
  1629.  
  1630.        Children are named 'wgAssigned' followed by the name or numeric
  1631.        of the particular working group assigned protocol. The above
  1632.        example would be named:
  1633.  
  1634.           'wgAssigned 1' or 'wgAssigned ipxOverRaw8023'"
  1635.  
  1636.     DECODING
  1637.        "The 'wgAssigned' base layer is a pseudo-protocol and is not
  1638.        decoded."
  1639.     REFERENCE
  1640.        "Refer to individual PROTOCOL-IDENTIFIER macros for information
  1641.        on each child of the working group assigned protocol."
  1642.     ::= { 5 }
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 28]
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657. Draft                  RMON Protocol Identifiers           November 1996
  1658.  
  1659.  
  1660. 5.2.5.1.  Working Group Assigned Protocol Identifiers
  1661.  
  1662. The following protocol-variant-identifier macro declarations are used to
  1663. identify the RMONMIB WG assigned protocols in a proprietary way, by
  1664. simple enumeration. Note that an additional four-octet layer identifier
  1665. may be used for some enumerations (as with the 'vsnap' base-layer
  1666. identifier). Refer to the 'CHILDREN' clause in the protocol-identifier
  1667. macro for a particular protocol to determine the number of octets in the
  1668. 'wgAssigned' layer-identifier.
  1669.  
  1670. ipxOverRaw8023 PROTOCOL-IDENTIFIER
  1671.     VARIANT-OF  "ipx"
  1672.     PARAMETERS  { }
  1673.     ATTRIBUTES  { }
  1674.     DESCRIPTION
  1675.        "This pseudo-protocol describes an encapsulation of IPX over
  1676.        802.3, without a type field.
  1677.  
  1678.        Refer to the macro for IPX for additional information about this
  1679.        protocol."
  1680.     DECODING
  1681.        "Whenever the 802.3 header indicates LLC a set of protocol
  1682.        specific tests needs to be applied to determine whether this is a
  1683.        'raw8023' packet or a true 802.2 packet.  The nature of these
  1684.        tests depends on the active child protocols for 'raw8023' and is
  1685.        beyond the scope of this document."
  1686.     ::= { wgAssigned 1 }
  1687.  
  1688.  
  1689. 5.3.  Protocol Stacks And Single-Vendor Applications
  1690.  
  1691. Network layer protocol identifier macros contain additional information
  1692. about the network layer, and is found immediately following a base
  1693. layer-identifier in a protocol identifier.
  1694.  
  1695. The ProtocolDirParameters supported at the network layer are
  1696. 'countsFragments(0)', and 'tracksSessions(1). An agent may choose to
  1697. implement a subset of these parameters.
  1698.  
  1699. The protocol-name should be used for the ProtocolDirDescr field.  The
  1700. ProtocolDirType ATTRIBUTES used at the network layer are
  1701. 'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose
  1702. to implement a subset of these attributes for each protocol, and
  1703. therefore limit which tables the indicated protocol can be present (e.g.
  1704. protocol distribution, host, and matrix tables)..
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 29]
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716. Draft                  RMON Protocol Identifiers           November 1996
  1717.  
  1718.  
  1719. The following protocol-identifier macro declarations are given for
  1720. example purposes only. They are not intended to constitute an exhaustive
  1721. list or an authoritative source for any of the protocol information
  1722. given.  However, any protocol that can encapsulate other protocols must
  1723. be documented here in order to encode the children identifiers into
  1724. protocolDirID strings. Leaf protocols should be documented as well, but
  1725. an implementation can identify a leaf protocol even if it isn't listed
  1726. here (as long as the parent is documented).
  1727.  
  1728.  
  1729. 5.3.1.  The TCP/IP protocol stack
  1730.  
  1731. arp PROTOCOL-IDENTIFIER
  1732.     PARAMETERS { }
  1733.     ATTRIBUTES { }
  1734.     DESCRIPTION
  1735.        "An Address Resolution Protocol message (request or response).
  1736.        This protocol does not include Reverse ARP (RARP) packets, which
  1737.        are counted separately."
  1738.     REFERENCE
  1739.        "RFC 826 [RFC826] defines the Address Resolution Protocol."
  1740.     ::= {
  1741.         ether2 0x806,   -- [ 0.0.8.6 ]
  1742.         snap 0x806
  1743.     }
  1744.  
  1745.  
  1746. ip PROTOCOL-IDENTIFIER
  1747.     PARAMETERS {
  1748.           countsFragments(0)  -- This parameter applies to all child
  1749.                               -- protocols.
  1750.     }
  1751.     ATTRIBUTES {
  1752.         hasChildren(0),
  1753.         addressRecognitionCapable(1)
  1754.     }
  1755.     DESCRIPTION
  1756.        "The protocol identifiers for the Internet Protocol (IP). Note
  1757.        that IP may be encapsulated within itself, so more than one of
  1758.        the following identifiers may be present in a particular
  1759.        protocolDirID string."
  1760.     CHILDREN
  1761.        "Children of 'ip' are selected by the value in the Protocol field
  1762.        (one octet), as defined in the PROTOCOL NUMBERS table within the
  1763.        Assigned Numbers Document.
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 30]
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775. Draft                  RMON Protocol Identifiers           November 1996
  1776.  
  1777.  
  1778.        The value of the Protocol field is encoded in an octet string as
  1779.        [ 0.0.0.a ], where 'a' is the protocol field .
  1780.  
  1781.        Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
  1782.        where 'a' is the protocol field value. For example, a
  1783.        protocolDirID-fragment value of:
  1784.           0.0.0.1.0.0.8.0.0.0.0.1
  1785.  
  1786.        defines an encapsulation of ICMP (ether2.ip.icmp)"
  1787.     ADDRESS-FORMAT
  1788.        "4 octets of the IP address, in network byte order.  Each ip
  1789.        packet contains two addresses, the source address and the
  1790.        destination address."
  1791.     DECODING
  1792.        "Note: ether2/ip/ipip4/udp is a different protocolDirID than
  1793.        ether2/ip/udp, as identified in the protocolDirTable. As such,
  1794.        two different local protocol index values will be assigned by the
  1795.        agent. E.g. (full INDEX values shown):
  1796.         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
  1797.         ether2/ip/udp       12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
  1798.     REFERENCE
  1799.        "RFC 791 [RFC791] defines the Internet Protocol; The following
  1800.        URL defines the authoritative repository for the PROTOCOL NUMBERS
  1801.        Table:
  1802.  
  1803.           ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
  1804.     ::= {
  1805.           ether2 0x0800,
  1806.           llc 0x06,
  1807.           snap 0x0800,
  1808.           ip 4,
  1809.           ip 94
  1810.     }
  1811.  
  1812.  
  1813. icmp PROTOCOL-IDENTIFIER
  1814.     PARAMETERS { }
  1815.     ATTRIBUTES { }
  1816.     DESCRIPTION
  1817.        "Internet Message Control Protocol."
  1818.     REFERENCE
  1819.        "RFC 792 [RFC792] defines the Internet Control Message Protocol."
  1820.     ::= { ip 1 }
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 31]
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834. Draft                  RMON Protocol Identifiers           November 1996
  1835.  
  1836.  
  1837. tcp  PROTOCOL-IDENTIFIER
  1838.     PARAMETERS { }
  1839.     ATTRIBUTES {
  1840.          hasChildren(0)
  1841.     }
  1842.     DESCRIPTION
  1843.        "Transmission Control Protocol."
  1844.     CHILDREN
  1845.        "Children of TCP are identified by the 16 bit Destination Port
  1846.        value as specified in RFC 793. They are encoded as [ 0.0.a.b],
  1847.        where 'a' is the MSB and 'b' is the LSB of the Destination Port
  1848.        value. Both bytes are encoded in network byte order.  For
  1849.        example, a protocolDirId-fragment of:
  1850.            0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
  1851.  
  1852.        identifies an encapsulation of the telnet protocol
  1853.        (ether2.ip.tcp.telnet)"
  1854.     REFERENCE
  1855.        "RFC 793 [RFC793] defines the Transmission Control Protocol.
  1856.  
  1857.        The following URL defines the authoritative repository for
  1858.        reserved and registered TCP port values:
  1859.  
  1860.          ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
  1861.     ::=  { ip 6 }
  1862.  
  1863.  
  1864. udp  PROTOCOL-IDENTIFIER
  1865.     PARAMETERS { }
  1866.     ATTRIBUTES {
  1867.          hasChildren(0)
  1868.     }
  1869.     DESCRIPTION
  1870.        "User Datagram Protocol."
  1871.     CHILDREN
  1872.        "Children of UDP are identified by the 16 bit Destination Port
  1873.        value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
  1874.        where 'a' is the MSB and 'b' is the LSB of the Destination Port
  1875.        value. Both bytes are encoded in network byte order.  For
  1876.        example, a protocolDirId-fragment of:
  1877.            0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
  1878.  
  1879.        identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
  1880.     REFERENCE
  1881.        "RFC 768 [RFC768] defines the User Datagram Protocol.
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 32]
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893. Draft                  RMON Protocol Identifiers           November 1996
  1894.  
  1895.  
  1896.        The following URL defines the authoritative repository for
  1897.        reserved and registered UDP port values:
  1898.  
  1899.          ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
  1900.    ::= { ip 17 }
  1901.  
  1902.  
  1903. ftp-data PROTOCOL-IDENTIFIER
  1904.     PARAMETERS { }
  1905.     ATTRIBUTES { }
  1906.     DESCRIPTION
  1907.        "The File Transfer Protocol Data Port; the FTP Server process
  1908.        default data-connection port. "
  1909.     REFERENCE
  1910.        "RFC 959 [RFC959] defines the File Transfer Protocol.  Refer to
  1911.        section 3.2 of [RFC959] for details on FTP data connections."
  1912.     ::= { tcp 20 }
  1913.  
  1914.  
  1915. ftp PROTOCOL-IDENTIFIER
  1916.     PARAMETERS { }
  1917.     ATTRIBUTES { }
  1918.     DESCRIPTION
  1919.        "The File Transfer Protocol Control Port; An FTP client initiates
  1920.        an FTP control connection by sending FTP commands from user port
  1921.        (U) to this port."
  1922.     REFERENCE
  1923.        "RFC 959 [RFC959] defines the File Transfer Protocol."
  1924.     ::= { tcp 21 }
  1925.  
  1926.  
  1927. telnet PROTOCOL-IDENTIFIER
  1928.     PARAMETERS { }
  1929.     ATTRIBUTES { }
  1930.     DESCRIPTION
  1931.        "The Telnet Protocol; The purpose of the TELNET Protocol is to
  1932.        provide a fairly general, bi-directional, eight-bit byte oriented
  1933.        communications facility.  Its primary goal is to allow a standard
  1934.        method of interfacing terminal devices and terminal-oriented
  1935.        processes to each other. "
  1936.     REFERENCE
  1937.        "RFC 854 [RFC854] defines the basic Telnet Protocol."
  1938.     ::= { tcp 23 }
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 33]
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952. Draft                  RMON Protocol Identifiers           November 1996
  1953.  
  1954.  
  1955. smtp PROTOCOL-IDENTIFIER
  1956.     PARAMETERS { }
  1957.     ATTRIBUTES { }
  1958.     DESCRIPTION
  1959.        "The Simple Mail Transfer Protocol; SMTP control and data
  1960.        messages are sent on this port."
  1961.     REFERENCE
  1962.        "RFC 821 [RFC821] defines the basic Simple Mail Transfer
  1963.        Protocol."
  1964.     ::= { tcp 25 }
  1965.  
  1966.  
  1967. -- [ed. - renamed from domain]
  1968. dns PROTOCOL-IDENTIFIER
  1969.     PARAMETERS { }
  1970.     ATTRIBUTES { }
  1971.     DESCRIPTION
  1972.        "Domain Name Service Protocol; DNS may be transported by either
  1973.        UDP [RFC768] or TCP [RFC793].  If the transport is UDP, DNS
  1974.        requests restricted to 512 bytes in length may be sent to this
  1975.        port."
  1976.     REFERENCE
  1977.        "RFC 1035 [RFC1035] defines the Bootstrap Protocol."
  1978.     ::= { udp 53,
  1979.           tcp 53  }
  1980.  
  1981.  
  1982. bootps PROTOCOL-IDENTIFIER
  1983.     PARAMETERS { }
  1984.     ATTRIBUTES { }
  1985.     DESCRIPTION
  1986.        "Bootstrap Protocol Server Protocol; BOOTP Clients send requests
  1987.        (usually broadcast) to the bootps port."
  1988.     REFERENCE
  1989.        "RFC 951 [RFC951] defines the Bootstrap Protocol."
  1990.     ::= { udp 67 }
  1991.  
  1992.  
  1993. bootpc PROTOCOL-IDENTIFIER
  1994.     PARAMETERS { }
  1995.     ATTRIBUTES { }
  1996.     DESCRIPTION
  1997.        "Bootstrap Protocol Client Protocol; BOOTP Server replies are
  1998.        sent to the BOOTP Client using this destination port."
  1999.     REFERENCE
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 34]
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011. Draft                  RMON Protocol Identifiers           November 1996
  2012.  
  2013.  
  2014.        "RFC 951 [RFC951] defines the Bootstrap Protocol."
  2015.     ::= { udp 68 }
  2016.  
  2017.  
  2018. tftp PROTOCOL-IDENTIFIER
  2019.     PARAMETERS {
  2020.         tracksSessions(1)
  2021.     }
  2022.     ATTRIBUTES { }
  2023.     DESCRIPTION
  2024.        "Trivial File Transfer Protocol; Only the first packet of each
  2025.        TFTP transaction will be sent to port 69. If the tracksSessions
  2026.        attribute is set, then packets for each TFTP transaction will be
  2027.        attributed to tftp, instead of the unregistered port numbers that
  2028.        will be encoded in subsequent packets."
  2029.     REFERENCE
  2030.        "RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
  2031.        1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
  2032.        defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
  2033.        TFTP Timeout Interval and Transfer Size Options."
  2034.  
  2035.     ::= { udp 69 }
  2036.  
  2037.  
  2038. www-http PROTOCOL-IDENTIFIER
  2039.     PARAMETERS { }
  2040.     ATTRIBUTES { }
  2041.     DESCRIPTION
  2042.        "Hypertext Transfer Protocol; "
  2043.     REFERENCE
  2044.        "RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
  2045.        (HTTP/1.0)."
  2046.     ::= { tcp 80 }
  2047.  
  2048.  
  2049. pop3 PROTOCOL-IDENTIFIER
  2050.     PARAMETERS { }
  2051.     ATTRIBUTES { }
  2052.     DESCRIPTION
  2053.        "Post Office Protocol -- Version 3. Clients establish connections
  2054.        with POP3 servers by using this destination port number."
  2055.     REFERENCE
  2056.        "RFC 1725 [RFC1725] defines Version 3 of the Post Office
  2057.        Protocol."
  2058.     ::= { tcp 110 }
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 35]
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070. Draft                  RMON Protocol Identifiers           November 1996
  2071.  
  2072.  
  2073. sunrpc PROTOCOL-IDENTIFIER
  2074.     PARAMETERS {
  2075.         tracksSessions(1) -- learn port mapping of programs
  2076.     }
  2077.     ATTRIBUTES {
  2078.         hasChildren(0),  -- port mapper function numbers
  2079.     }
  2080.     DESCRIPTION
  2081.        "SUN Remote Procedure Call Protocol. Port mapper function
  2082.        requests are sent to this destination port."
  2083.     CHILDREN
  2084.        Specific RPC functions are represented as children of the sunrpc
  2085.        protocol. Each 'RPC function protocol' is identified by its
  2086.        function number assignment. RPC function number assignments are
  2087.        defined by different naming authorities, depending on the
  2088.        function identifier value.
  2089.        From [RFC1831]:
  2090.  
  2091.        Program numbers are given out in groups of hexadecimal 20000000
  2092.        (decimal 536870912) according to the following chart:
  2093.  
  2094.                      0 - 1fffffff   defined by rpc@sun.com
  2095.               20000000 - 3fffffff   defined by user
  2096.               40000000 - 5fffffff   transient
  2097.               60000000 - 7fffffff   reserved
  2098.               80000000 - 9fffffff   reserved
  2099.               a0000000 - bfffffff   reserved
  2100.               c0000000 - dfffffff   reserved
  2101.               e0000000 - ffffffff   reserved
  2102.  
  2103.        Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
  2104.        identifier component for 'sunrpc', followed by [ a.b.c.d ], where
  2105.        a.b.c.d is the 32 bit binary RPC program number encoded in
  2106.        network byte order.  For example, a protocolDirID-fragment value
  2107.        of:
  2108.            0.0.0.111.0.1.134.163
  2109.  
  2110.        defines the NFS function (and protocol).
  2111.  
  2112.        Children are named as 'sunrpc' followed by the RPC function
  2113.        number in base 10 format. For example, NFS would be named:
  2114.            'sunrpc 100003'.
  2115.     DECODING
  2116.        "The first packet of many SUNRPC transactions is sent to the
  2117.        port- mapper program, and therefore decoded statically by
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 36]
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129. Draft                  RMON Protocol Identifiers           November 1996
  2130.  
  2131.  
  2132.        monitoring RFC portmap requests [RFC1831]. Any subsequent packets
  2133.        must be decoded and correctly identified by 'remembering' the
  2134.        port assignments used in each RPC function call (as identified
  2135.        according to the procedures in the RPC Specification Version 2
  2136.        [RFC1831]).
  2137.  
  2138.        In some cases the port mapping for a particular protocol is well
  2139.        known and hard coded into the requesting client.  In these cases
  2140.        the client will not send portmap requests; instead it will send
  2141.        the SUNRPC request directly to the well known port.  These cases
  2142.        are rare and are being eliminated over time.  NFS is the most
  2143.        significant SUNRPC program of this class.  Such programs should
  2144.        still be declared as children of SUNRPC as described under
  2145.        CHILDREN above.  How an implementation detects this behaviour and
  2146.        handles it is beyond the scope of this document.
  2147.  
  2148.        The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
  2149.        the probe can (and should) monitor portmapper activity to
  2150.        correctly track SUNRPC connections."
  2151.     REFERENCE
  2152.        "RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
  2153.        Version 2.  The authoritative list of RPC Functions is identified
  2154.        by the URL:
  2155.            ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
  2156.     ::= { udp 111 }
  2157.  
  2158.  
  2159. portmapper PROTOCOL-IDENTIFIER
  2160.     PARAMETERS { }
  2161.     ATTRIBUTES { }
  2162.     DESCRIPTION
  2163.        "SUNRPC PORTMAPPER program.  This is the SUNRPC program which is
  2164.        used to locate the UDP/TCP ports on which other SUNRPC programs
  2165.        can be found."
  2166.     REFERENCE
  2167.        "Appendix A of RFC 1057 [RFC1057] describes the portmapper
  2168.        operation."
  2169.     ::= { sunrpc 100000 }
  2170.  
  2171.  
  2172. nfs  PROTOCOL-IDENTIFIER
  2173.     PARAMETERS { }
  2174.     ATTRIBUTES { }
  2175.     DESCRIPTION
  2176.        "Sun Network File System (NFS);"
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 37]
  2183.  
  2184.  
  2185.  
  2186.  
  2187.  
  2188. Draft                  RMON Protocol Identifiers           November 1996
  2189.  
  2190.  
  2191.     DECODING
  2192.        "NFS is a SUNRPC program which may or may not use the port mapper
  2193.        SUNRPC program to connect clients and servers.  In many cases the
  2194.        NFS server program runs over UDP/TCP port 2049, but an
  2195.        implementation is encouraged to perform further analysis before
  2196.        assuming that a packet to/from this port is a SUNRPC/NFS packet.
  2197.        Likewise an implementation is encouraged to track port mapper
  2198.        activity to spot cases where it is used to locate the SUNRPC/NFS
  2199.        program as this is more robust."
  2200.     REFERENCE
  2201.        "The NFS Version 3 Protocol Specification is defined in RFC 1813
  2202.        [RFC1813]."
  2203.     ::= {
  2204.         sunrpc 100003           --  [0.1.134.163]
  2205.     }
  2206.  
  2207.  
  2208. xwin PROTOCOL-IDENTIFIER
  2209.     PARAMETERS {
  2210.         tracksSessions(1)
  2211.     }
  2212.     ATTRIBUTES { }
  2213.     DESCRIPTION
  2214.        "X Windows Protocol"
  2215.     DECODING
  2216.        "The X Windows Protocol when run over UDP/TCP normally runs over
  2217.        the well known port 6000.  It can run over any port in the range
  2218.        6000 to 6063, however.  If the tracksSessions(1) parameter bit is
  2219.        set the agent can and should detect such X Window sessions and
  2220.        report them as the X protocol."
  2221.     REFERENCE
  2222.          "The X Windows Protocol is defined by TBD"
  2223.     ::= {
  2224.          tcp 6000
  2225.          udp 6000
  2226.          -- lat ?
  2227.     }
  2228.  
  2229. 5.3.2.  Novell IPX Stack
  2230.  
  2231. ipx PROTOCOL-IDENTIFIER
  2232.     PARAMETERS { }
  2233.     ATTRIBUTES {
  2234.          hasChildren(0),
  2235.          addressRecognitionCapable(1)
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 38]
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247. Draft                  RMON Protocol Identifiers           November 1996
  2248.  
  2249.  
  2250.     }
  2251.     DESCRIPTION
  2252.        "Novell IPX"
  2253.     CHILDREN
  2254.        "Children of IPX are defined by the 8 bit packet type field.  The
  2255.        value is encoded into an octet string as [ 0.0.0.a ], where 'a'
  2256.        is the single octet of the packet type field.
  2257.  
  2258.        Notice that in many implementations of IPX usage of the packet
  2259.        type field is inconsistent with the specification and
  2260.        implementations are encouraged to use other techniques to map
  2261.        inconsistent values to the correct value (which in these cases is
  2262.        typically the Packet Exchange Protocol).  It is beyond the scope
  2263.        of this document to describe these techniques in more detail.
  2264.  
  2265.        Children of IPX are encoded as [ 0.0.0.a ], and named as 'ipx a'
  2266.        where a is the packet type value.  The novell echo protocol is
  2267.        referred to as 'ipx nov-echo' OR 'ipx 2'."
  2268.     ADDRESS-FORMAT
  2269.        "4 bytes of Network number followed by the 6 bytes Host address
  2270.        each in network byte order."
  2271.     REFERENCE
  2272.        "The IPX protocol is defined by the Novell Corporation
  2273.  
  2274.        A complete description of IPX may be secured at the following
  2275.        address:
  2276.               Novell, Inc.
  2277.               122 East 1700 South
  2278.               P. O. Box 5900
  2279.               Provo, Utah 84601 USA
  2280.               800 526 5463
  2281.               Novell Part # 883-000780-001"
  2282.     ::= {
  2283.         ether2     0x8137,           -- 0.0.129.55
  2284.         llc        0xe0e003,         -- 0.224.224.3
  2285.         snap       0x8137,           -- 0.0.129.55
  2286.         wgAssigned 0x1               -- 0.0.0.1   (ipxOverRaw8023)
  2287.     }
  2288.  
  2289.  
  2290. nov-rip PROTOCOL-IDENTIFIER
  2291.     PARAMETERS { }
  2292.     ATTRIBUTES { }
  2293.     DESCRIPTION
  2294.        "Novell Routing Information Protocol."
  2295.  
  2296.  
  2297.  
  2298.  
  2299.  
  2300. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 39]
  2301.  
  2302.  
  2303.  
  2304.  
  2305.  
  2306. Draft                  RMON Protocol Identifiers           November 1996
  2307.  
  2308.  
  2309.     REFERENCE
  2310.        "[TBD]"
  2311.     ::= {
  2312.            ipx 0x01 -- when reached by IPX packet type
  2313.            nov-pep 0x0453 -- when reached by IPX socket number
  2314.     }
  2315.  
  2316.  
  2317. nov-echo PROTOCOL-IDENTIFIER
  2318.     PARAMETERS { }
  2319.     ATTRIBUTES { }
  2320.     DESCRIPTION
  2321.        "Novell Echo protocol."
  2322.     REFERENCE
  2323.        "[TBD]"
  2324.     ::= { ipx 0x02 }
  2325.  
  2326.  
  2327. nov-error PROTOCOL-IDENTIFIER
  2328.     PARAMETERS { }
  2329.     ATTRIBUTES { }
  2330.     DESCRIPTION
  2331.        "Novell Error-handler protocol."
  2332.     REFERENCE
  2333.        "[TBD]"
  2334.     ::= { ipx 0x03 }
  2335.  
  2336.  
  2337. nov-pep PROTOCOL-IDENTIFIER
  2338.     PARAMETERS { }
  2339.     ATTRIBUTES {
  2340.         hasChildren(0)
  2341.     }
  2342.     DESCRIPTION
  2343.        "Novell Packet Exchange Protocol.  This is really a null protocol
  2344.        layer as all IPX packets contain the relevant fields for this
  2345.        protocol.  This protocol is defined so that socket-based decoding
  2346.        has a point of attachment in the decode tree while still allowing
  2347.        packet type based decoding also."
  2348.     CHILDREN
  2349.        "Children of PEP are defined by the 16 bit socket values.  The
  2350.        value is encoded into an octet string as [ 0.0.a.b ], where 'a'
  2351.        and 'b' are the network byte order encodings of the MSB and LSB
  2352.        of the socket value.
  2353.  
  2354.  
  2355.  
  2356.  
  2357.  
  2358.  
  2359. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 40]
  2360.  
  2361.  
  2362.  
  2363.  
  2364.  
  2365. Draft                  RMON Protocol Identifiers           November 1996
  2366.  
  2367.  
  2368.        Each IPX/PEP packet contains two sockets, source and destination.
  2369.        How these are mapped onto the single well-known socket value used
  2370.        to identify its children is beyond the scope of this document."
  2371.     REFERENCE
  2372.        "[TBD]"
  2373.     ::= {
  2374.         ipx 0x00 -- Many third party IPX's use this value always
  2375.         ipx 0x04 -- Xerox assigned for PEP
  2376.         ipx 0x11 -- Novell use this for PEP packets, often
  2377.     }
  2378.  
  2379.  
  2380. nov-spx PROTOCOL-IDENTIFIER
  2381.     PARAMETERS { }
  2382.     ATTRIBUTES {
  2383.     hasChildren(0)
  2384.  }
  2385.     DESCRIPTION
  2386.        "Novell Sequenced Packet Exchange Protocol.  This protocol is an
  2387.        extension of IPX/PEP as it shares a common header."
  2388.     CHILDREN
  2389.        "Children of SPX are defined by the 16 bit socket values.  The
  2390.        value is encoded into an octet string as [ 0.0.a.b ], where 'a'
  2391.        and 'b' are the network byte order encodings of the MSB and LSB
  2392.        of the socket value.
  2393.  
  2394.        Each IPX/SPX packet contains two sockets, source and destination.
  2395.        How these are mapped onto the single well-known socket value used
  2396.        to identify its children is beyond the scope of this document."
  2397.     REFERENCE
  2398.           "[TBD]"
  2399.     ::= {
  2400.         ipx 0x05 -- Xerox assigned for SPX
  2401.     }
  2402.  
  2403.  
  2404. nov-sap PROTOCOL-IDENTIFIER
  2405.     PARAMETERS {
  2406.         tracksSessions(1)
  2407.     }
  2408.     ATTRIBUTES {
  2409.         hasChildren(0),
  2410.     }
  2411.     DESCRIPTION
  2412.        "Novell Service Advertising Protocol.  This protocol binds
  2413.  
  2414.  
  2415.  
  2416.  
  2417.  
  2418. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 41]
  2419.  
  2420.  
  2421.  
  2422.  
  2423.  
  2424. Draft                  RMON Protocol Identifiers           November 1996
  2425.  
  2426.  
  2427.        applications on a particular host to an IPX/PEP or IPX/SPX socket
  2428.        number.  Although it never truly acts as a transport protocol
  2429.        itself it is used to establish sessions between clients and
  2430.        servers and barring well-known sockets is the only reliable way
  2431.        to determine the protocol running over a given socket on a given
  2432.        machine."
  2433.     CHILDREN
  2434.        "Children of SAP are identified by a 16 bit service type.  They
  2435.        are encoded as [ 0.0.a.b ], where 'a' is the MSB and 'b' is the
  2436.        LSB of the service type.
  2437.  
  2438.        Children of SAP are named as 'nov-sap a' where 'a' is the service
  2439.        type in hexadecimal notation.  The novell NCP protocol is
  2440.        referred to as 'nov-sap ncp' OR 'nov-sap 0x0004'."
  2441.     DECODING
  2442.        "The first packet of any session for a SAP based application
  2443.        (almost all IPX/PEP and IPX/SPX based applications utilize SAP)
  2444.        is sent to the SAP server(s) to map the service type into a port
  2445.        number for the host(s) on which the SAP server(s) is(are)
  2446.        running.  These initial packets are SAP packets and not
  2447.        application packets and must be decoded accordingly.
  2448.  
  2449.        Having established the mapping, clients will then send
  2450.        application packets to the newly discovered socket number.  These
  2451.        must be decoded by 'remembering' the socket assignments
  2452.        transmitted in the SAP packets.
  2453.  
  2454.        In some cases the port mapping for a particular protocol is well
  2455.        known and SAP will always return the same socket number for that
  2456.        application.
  2457.  
  2458.        Such programs should still be declared as children of nov-sap as
  2459.        described under CHILDREN above.  How an implementation detects a
  2460.        client which is bypassing the SAP server to contact a well-known
  2461.        application is beyond the scope of this document.
  2462.  
  2463.        The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
  2464.        the probe can (and should) monitor nov-sap activity to correctly
  2465.        track SAP-based connections."
  2466.     REFERENCE
  2467.        "A list of SAP service types can be found at
  2468.           ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-
  2469.        numbers"
  2470.     ::= { nov-pep 0x0452 }
  2471.  
  2472.  
  2473.  
  2474.  
  2475.  
  2476.  
  2477. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 42]
  2478.  
  2479.  
  2480.  
  2481.  
  2482.  
  2483. Draft                  RMON Protocol Identifiers           November 1996
  2484.  
  2485.  
  2486. ncp PROTOCOL-IDENTIFIER
  2487.     PARAMETERS {
  2488.         tracksSessions(1)
  2489.     }
  2490.     ATTRIBUTES {
  2491.         hasChildren(0)
  2492.     }
  2493.     DESCRIPTION
  2494.        "Netware Core Protocol"
  2495.     CHILDREN
  2496.        "Children of NCP are identified by the 8 bit command type field.
  2497.        They are encoded as [ 0.0.0.a ] where 'a' is the command type
  2498.        value.
  2499.  
  2500.        Children of NCP are named as 'ncp a' where 'a' is the command
  2501.        type in decimal notation.  The NDS sub-protocol is referred to as
  2502.        'ncp nds' OR 'ncp 104'."
  2503.     DECODING
  2504.        "Only the NCP request frames carry the command type field.  How
  2505.        the implementation infers the command type of a response frame is
  2506.        an implementation specific matter and beyond the scope of this
  2507.        document.
  2508.  
  2509.        The tracksSessions(1) PARAMETERS bit indicates whether the probe
  2510.        can (and should) perform command type inference."
  2511.     REFERENCE
  2512.        "[TBD]"
  2513.     ::= { nov-sap 0x0004 }  -- NB This one is always socket 0x0451
  2514.  
  2515.  
  2516. nds PROTOCOL-IDENTIFIER
  2517.     PARAMETERS { }
  2518.     ATTRIBUTES { }
  2519.     DESCRIPTION
  2520.          "The Netware Directory Services sub-protocol."
  2521.     REFERENCE
  2522.        "[TBD]"
  2523.     ::= { ncp 104 }
  2524.  
  2525.  
  2526. nov-diag PROTOCOL-IDENTIFIER
  2527.     PARAMETERS { }
  2528.     ATTRIBUTES { }
  2529.     DESCRIPTION
  2530.        "Novell's diagnostic protocol."
  2531.  
  2532.  
  2533.  
  2534.  
  2535.  
  2536. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 43]
  2537.  
  2538.  
  2539.  
  2540.  
  2541.  
  2542. Draft                  RMON Protocol Identifiers           November 1996
  2543.  
  2544.  
  2545.     REFERENCE
  2546.        "[TBD]"
  2547.     ::= {
  2548.         nov-sap 0x0017 -- this is the right one
  2549.         -- [ed. this one is also typically true but, derivable from the one
  2550.         -- above at run-time (I think this is the same thing).
  2551.         -- ipx 0x0456]
  2552.     }
  2553.  
  2554.  
  2555. nov-sec PROTOCOL-IDENTIFIER
  2556.     PARAMETERS { }
  2557.     ATTRIBUTES { }
  2558.     DESCRIPTION
  2559.        "Novell security - serialization - copy protection protocol."
  2560.     REFERENCE
  2561.        "[TBD]"
  2562.     ::= { nov-pep 0x0457 }
  2563.  
  2564.  
  2565. nov-watchdog PROTOCOL-IDENTIFIER
  2566.     PARAMETERS { }
  2567.     ATTRIBUTES { }
  2568.     DESCRIPTION
  2569.        "Novell watchdog protocol."
  2570.     REFERENCE
  2571.        "[TBD]"
  2572.     ::= { nov-pep 0x4004 }
  2573.  
  2574.  
  2575. nov-bcast PROTOCOL-IDENTIFIER
  2576.     PARAMETERS { }
  2577.     ATTRIBUTES { }
  2578.     DESCRIPTION
  2579.        "Novell broadcast protocol."
  2580.     REFERENCE
  2581.        "[TBD]"
  2582.     ::= { nov-pep 0x4005 }
  2583.  
  2584.  
  2585. 5.3.3.  The XEROX Protocol Stack
  2586.  
  2587. idp PROTOCOL-IDENTIFIER
  2588.     PARAMETERS { }
  2589.     ATTRIBUTES {
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 44]
  2596.  
  2597.  
  2598.  
  2599.  
  2600.  
  2601. Draft                  RMON Protocol Identifiers           November 1996
  2602.  
  2603.  
  2604.          hasChildren(0),
  2605.          addressRecognitionCapable(1)
  2606.     }
  2607.     DESCRIPTION
  2608.        "Xerox IDP"
  2609.     CHILDREN
  2610.        "Children of IDP are defined by the 8 bit value of the Packet
  2611.        type field.  The value is encoded into an octet string as [
  2612.        0.0.0.a ], where 'a' is the value of the packet type field in
  2613.        network byte order.
  2614.  
  2615.        Children of IPX are encoded as [ 0.0.0.a ], and named as 'ipx a'
  2616.        where a is the packet type value.  The XNS SPP protocol is
  2617.        referred to as 'idp xns-spp' OR 'idp 2'."
  2618.     ADDRESS-FORMAT
  2619.        "4 bytes of Network number followed by the 6 bytes Host address
  2620.        each in network byte order."
  2621.     REFERENCE
  2622.        "Xerox Corporation, Document XNSS 028112, 1981"
  2623.     ::=  {
  2624.        ether2  0x600,     -- [ 0.0.6.0 ]
  2625.        snap    0x600
  2626.     }
  2627.  
  2628.  
  2629. xns-rip PROTOCOL-IDENTIFIER
  2630.     PARAMETERS { }
  2631.     ATTRIBUTES { }
  2632.     DESCRIPTION
  2633.        "Routing Information Protocol."
  2634.     REFERENCE
  2635.        "[TBD]"
  2636.     ::= { idp 1 }
  2637.  
  2638.  
  2639. xns-echo PROTOCOL-IDENTIFIER
  2640.     PARAMETERS { }
  2641.     ATTRIBUTES { }
  2642.     DESCRIPTION
  2643.        "XNS echo protocol."
  2644.     REFERENCE
  2645.        "[TBD]"
  2646.     ::= { idp 2 }
  2647.  
  2648.  
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 45]
  2655.  
  2656.  
  2657.  
  2658.  
  2659.  
  2660. Draft                  RMON Protocol Identifiers           November 1996
  2661.  
  2662.  
  2663. xns-error PROTOCOL-IDENTIFIER
  2664.     PARAMETERS { }
  2665.     ATTRIBUTES { }
  2666.     DESCRIPTION
  2667.        "XNS error-handler protocol."
  2668.     REFERENCE
  2669.        "[TBD]"
  2670.     ::= { idp 3 }
  2671.  
  2672.  
  2673. xns-pep PROTOCOL-IDENTIFIER
  2674.     PARAMETERS { }
  2675.     ATTRIBUTES {
  2676.         hasChildren(0)
  2677.     }
  2678.     DESCRIPTION
  2679.        "XNS Packet Exchange Protocol."
  2680.     CHILDREN
  2681.        "Children of PEP are defined by the 16 bit socket values.  The
  2682.        value is encoded into an octet string as [ 0.0.a.b ], where 'a'
  2683.        and 'b' are the network byte order encodings of the MSB and LSB
  2684.        of the socket value.
  2685.  
  2686.        Each XNS/PEP packet contains two sockets, source and destination.
  2687.        How these are mapped onto the single well-known socket value used
  2688.        to identify its children is beyond the scope of this document."
  2689.     REFERENCE
  2690.        "[TBD]"
  2691.     ::= { idp 4 }
  2692.  
  2693.  
  2694. xns-spp PROTOCOL-IDENTIFIER
  2695.     PARAMETERS { }
  2696.     ATTRIBUTES {
  2697.         hasChildren(0)
  2698.     }
  2699.     DESCRIPTION
  2700.        "Sequenced Packet Protocol."
  2701.     CHILDREN
  2702.        "Children of SPP are defined by the 16 bit socket values.  The
  2703.        value is encoded into an octet string as [ 0.0.a.b ], where 'a'
  2704.        and 'b' are the network byte order encodings of the MSB and LSB
  2705.        of the socket value.
  2706.  
  2707.        Each XNS/SPP packet contains two sockets, source and destination.
  2708.  
  2709.  
  2710.  
  2711.  
  2712.  
  2713. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 46]
  2714.  
  2715.  
  2716.  
  2717.  
  2718.  
  2719. Draft                  RMON Protocol Identifiers           November 1996
  2720.  
  2721.  
  2722.        How these are mapped onto the single well-known socket value used
  2723.        to identify its children is beyond the scope of this document."
  2724.     REFERENCE
  2725.        "[TBD]"
  2726.     ::= { idp 5 }
  2727.  
  2728.  
  2729. 5.3.4.  AppleTalk Protocol Stack
  2730.  
  2731. aarp PROTOCOL-IDENTIFIER
  2732.     PARAMETERS { }
  2733.     ATTRIBUTES { }
  2734.     DESCRIPTION
  2735.        "AppleTalk Address Resolution Protocol."
  2736.     REFERENCE
  2737.        "AppleTalk Phase 2 Protocol Specification, document ADPA
  2738.         #C0144LL/A."
  2739.     ::=   {
  2740.         ether2 0x80f3,  --  [ 0.0.128.243 ]
  2741.         vsnap-ether2 0x80f3
  2742.     }
  2743.  
  2744. -- Should we call this alap (as in ELAP and TLAP?)
  2745. -- Or perhaps DDP?
  2746.  
  2747.  
  2748. atalk PROTOCOL-IDENTIFIER
  2749.     PARAMETERS { }
  2750.     ATTRIBUTES {
  2751.         hasChildren(0),
  2752.         addressRecognitionCapable(1)
  2753.     }
  2754.     DESCRIPTION
  2755.        "AppleTalk Protocol."
  2756.     CHILDREN
  2757.        "Children of ATALK are defined by the 8 bit value of the DDP type
  2758.        field.  The value is encoded into an octet string as [ 0.0.0.a ],
  2759.        where 'a' is the value of the DDP type field in network byte
  2760.        order."
  2761.     ADDRESS-FORMAT
  2762.        "2 bytes of Network number followed by 1 byte of node id each in
  2763.        network byte order."
  2764.     REFERENCE
  2765.        "AppleTalk Phase 2 Protocol Specification, document ADPA
  2766.         #C0144LL/A."
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 47]
  2773.  
  2774.  
  2775.  
  2776.  
  2777.  
  2778. Draft                  RMON Protocol Identifiers           November 1996
  2779.  
  2780.  
  2781.     ::=   {
  2782.         ether2  0x809b,   -- [ 0.0.128.155 ]
  2783.         vsnap-ether2 0x809b
  2784.     }
  2785.  
  2786.  
  2787. rtmp PROTOCOL-IDENTIFIER
  2788.     PARAMETERS { }
  2789.     ATTRIBUTES { }
  2790.     DESCRIPTION
  2791.        "AppleTalk Routing Table Maintenance Protocol."
  2792.     REFERENCE
  2793.        "[TBD]"
  2794.     ::= {
  2795.         atalk   0x01,       -- responses
  2796.         atalk   0x05        -- requests
  2797.     }
  2798.  
  2799.  
  2800. aep PROTOCOL-IDENTIFIER
  2801.     PARAMETERS { }
  2802.     ATTRIBUTES { }
  2803.     DESCRIPTION
  2804.        "AppleTalk Echo Protocol."
  2805.     REFERENCE
  2806.          "[TBD]"
  2807.     ::= { atalk 0x04 }
  2808.  
  2809.  
  2810. nbp PROTOCOL-IDENTIFIER
  2811.     PARAMETERS { }
  2812.     ATTRIBUTES { }
  2813.     DESCRIPTION
  2814.        "AppleTalk Name Binding Protocol."
  2815.     DECODING
  2816.        "In order to correctly identify the application protocol running
  2817.        over atp NBP packets must be analyzed.  The mechanism by which
  2818.        this is achieved is beyond the scope of this document."
  2819.     REFERENCE
  2820.        "[TBD]"
  2821.     ::= { atalk 0x02 }
  2822.  
  2823.  
  2824. zip PROTOCOL-IDENTIFIER
  2825.     PARAMETERS { }
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 48]
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837. Draft                  RMON Protocol Identifiers           November 1996
  2838.  
  2839.  
  2840.     ATTRIBUTES { }
  2841.     DESCRIPTION
  2842.        "AppleTalk Zone Information Protocol."
  2843.     REFERENCE
  2844.        "[TBD]"
  2845.     ::= {
  2846.         atalk   0x06,
  2847.         atp     3
  2848.     }
  2849.  
  2850.  
  2851. atp PROTOCOL-IDENTIFIER
  2852.     PARAMETERS {
  2853.         tracksSessions(1)
  2854.     }
  2855.     ATTRIBUTES {
  2856.         hasChildren(0)
  2857.     }
  2858.     DESCRIPTION
  2859.        "AppleTalk Transaction Protocol."
  2860.     CHILDREN
  2861.        "Children of atp are identified by the following (32 bit)
  2862.        enumeration:
  2863.          1   asp (AppleTalk Session Protocol)
  2864.          2   pap (Printer Access Protocol)
  2865.          3   zip (Zone Information Protocol)
  2866.        Children of atp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
  2867.        and 'd' are the four octets of the enumerated value in network
  2868.        order (i.e. 'a' is the MSB and 'd' is the LSB).
  2869.  
  2870.        The ZIP protocol is referred to as 'atp zip' OR 'atp 3'."
  2871.     DECODING
  2872.        "An implementation is encouraged to examine both the socket
  2873.        fields in the associated DDP header as well as the contents of
  2874.        prior NBP packets in order to determine which (if any) child is
  2875.        present.  A full description of this algorithm is beyond the
  2876.        scope of this document.  The tracksSessions(1) PARAMETER
  2877.        indicates whether the probe can (and should) perform this
  2878.        analysis."
  2879.     REFERENCE
  2880.        "[TBD]"
  2881.     ::= { atalk 0x03 }
  2882.  
  2883.  
  2884. adsp PROTOCOL-IDENTIFIER
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 49]
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896. Draft                  RMON Protocol Identifiers           November 1996
  2897.  
  2898.  
  2899.     PARAMETERS {
  2900.         tracksSessions(1)
  2901.     }
  2902.     ATTRIBUTES {
  2903.         hasChildren(0)
  2904.     }
  2905.     DESCRIPTION
  2906.        "AppleTalk Data Stream Protocol."
  2907.     CHILDREN
  2908.        "Children of adsp are identified by enumeration.  At this time
  2909.        none are known."
  2910.     DECODING
  2911.        "An implementation is encouraged to examine the socket numbers in
  2912.        the associated DDP header as well as the contents of prior NBP
  2913.        packets in order to determine which (if any) child of ADSP is
  2914.        present.
  2915.  
  2916.        The mechanism by which this is achieved is beyond the scope of
  2917.        this document.
  2918.  
  2919.        The tracksSessions(1) PARAMETER indicates whether the probe can
  2920.        (and should) perform this analysis."
  2921.     REFERENCE
  2922.        "[TBD]"
  2923.     ::= { atalk 0x07 }
  2924.  
  2925.  
  2926. asp PROTOCOL-IDENTIFIER
  2927.  PARAMETERS { }
  2928.     ATTRIBUTES {
  2929.   hasChildren(0)
  2930.  }
  2931.     DESCRIPTION
  2932.        "AppleTalk Session Protocol."
  2933.     CHILDREN
  2934.        "Children of asp are identified by the following (32 bit)
  2935.        enumeration:
  2936.          1   afp (AppleTalk Filing Protocol)
  2937.        Children of asp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
  2938.        and 'd' are the four octets of the enumerated value in network
  2939.        order (i.e. 'a' is the MSB and 'd' is the LSB).
  2940.  
  2941.        The AFP protocol is referred to as 'asp afp' OR 'asp 1'."
  2942.     DECODING
  2943.        "ASP is a helper layer to assist in building client/server
  2944.  
  2945.  
  2946.  
  2947.  
  2948.  
  2949. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 50]
  2950.  
  2951.  
  2952.  
  2953.  
  2954.  
  2955. Draft                  RMON Protocol Identifiers           November 1996
  2956.  
  2957.  
  2958.        protocols.  It cooperates with ATP to achieve this; the
  2959.        mechanisms used when decoding ATP apply equally here (i.e.
  2960.        checking DDP socket numbers and tracking NBP packets).
  2961.  
  2962.        Hence the tracksSessions(1) PARAMETER of atp applies to this
  2963.        protocol also."
  2964.     REFERENCE
  2965.        "[TBD]"
  2966.     ::= { atp 1 }
  2967.  
  2968.  
  2969. afp PROTOCOL-IDENTIFIER
  2970.     PARAMETERS { }
  2971.     ATTRIBUTES { }
  2972.     DESCRIPTION
  2973.          "AppleTalk Filing Protocol."
  2974.     REFERENCE
  2975.        "[TBD]"
  2976.     ::= { asp 1 }
  2977.  
  2978.  
  2979. pap PROTOCOL-IDENTIFIER
  2980.     PARAMETERS { }
  2981.     ATTRIBUTES { }
  2982.     DESCRIPTION
  2983.        "AppleTalk Printer Access Protocol."
  2984.     REFERENCE
  2985.        "[TBD]"
  2986.     ::= { atp 2 }
  2987.  
  2988.  
  2989. 5.3.5.  Banyon Vines Protocol Stack
  2990.  
  2991. -- vfrp PROTOCOL-IDENTIFIER
  2992. --  PARAMETERS {
  2993. --      countsFragments(0)
  2994. --  }
  2995. --  ATTRIBUTES {
  2996. --      hasChildren(0)
  2997. --  }
  2998. --  DESCRIPTION
  2999. --      "Vines Fragmentation Protocol header.
  3000. --      We will need this one for non-LAN media."
  3001. --  CHILDREN
  3002. --      "Children of vines-frp are identified by the etherType that they
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 51]
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014. Draft                  RMON Protocol Identifiers           November 1996
  3015.  
  3016.  
  3017. --      would have used over ether2 encapsulation.  It is an implementation
  3018. --      specific matter as to how these are determined in environments where
  3019. --      vines-frp is used."
  3020. --  ::= {
  3021. --       arcnet 0xf501 .. maps to vines-ip (0x0BAD)
  3022. --       arcnet 0xf502 .. maps to vines-echo (0x0BAF)
  3023. --       hdlc ????
  3024. --       ...
  3025. --  }
  3026.  
  3027.  
  3028. vtr PROTOCOL-IDENTIFIER
  3029.     PARAMETERS { }
  3030.     ATTRIBUTES {
  3031.         hasChildren(0)
  3032.     }
  3033.     DESCRIPTION
  3034.        "Banyan Vines Token Ring Protocol Header."
  3035.     CHILDREN
  3036.        "Children of vines-tr are identified by the 8 bit packet type
  3037.        field.  Children are encoded as [ 0.0.0.a ] where 'a' is the
  3038.        packet type value.
  3039.  
  3040.        The vines-ip protocol is referred to as 'vines-tr vip' OR
  3041.        'vines-tr 0xba'."
  3042.     REFERENCE
  3043.        "See vip."
  3044.     ::= { llc 0xBC } -- declared as any LLC, but really TR only.
  3045.  
  3046.  
  3047. vecho PROTOCOL-IDENTIFIER
  3048.     PARAMETERS { }
  3049.     ATTRIBUTES { }
  3050.     DESCRIPTION
  3051.        "Banyan Vines data link level echo protocol."
  3052.     REFERENCE
  3053.        "See vip."
  3054.     ::= {
  3055.         ether2      0x0BAF,
  3056.         snap        0x0BAF,
  3057.         -- vfrp 0x0BAF,
  3058.         vtr    0xBB    -- [ed. yuck!]
  3059.      }
  3060.  
  3061.  
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 52]
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073. Draft                  RMON Protocol Identifiers           November 1996
  3074.  
  3075.  
  3076. vip PROTOCOL-IDENTIFIER
  3077.     PARAMETERS { }
  3078.     ATTRIBUTES {
  3079.         hasChildren(0),
  3080.         addressRecognitionCapable(1)
  3081.     }
  3082.     DESCRIPTION
  3083.        "Banyan Vines Internet Protocol."
  3084.     CHILDREN
  3085.        "Children of vip are selected by the one-byte 'protocol type'
  3086.        field located at offset 5 in the vip header.  The value is
  3087.        encoded as [ 0.0.0.a ], where a is the 'protocol type.'  For
  3088.        example, a protocolDirId fragment of:
  3089.  
  3090.           0.0.0.1.0.0.11.173.0.0.0.1
  3091.  
  3092.          identifies an encapsulation of vipc (ether2.vip.vipc)."
  3093.     ADDRESS-FORMAT
  3094.        "vip packets have 6-byte source and destination addresses.  The
  3095.        destination address is located at offset 6 in the vip header, and
  3096.        the source address at offset 12.  These are encoded in network
  3097.        byte order."
  3098.     REFERENCE
  3099.        "Vines Protocol Definition - part# 092093-001, order# 003673
  3100.          BANYAN,
  3101.          120 Flanders Road,
  3102.          Westboro, MA 01581 USA"
  3103.     ::= {
  3104.         ether2  0x0BAD,
  3105.         snap    0x0BAD,
  3106.         -- vfrp 0x0BAD,
  3107.         vtr    0xBA    -- [ed. yuck!]
  3108.     }
  3109.  
  3110.  
  3111. varp PROTOCOL-IDENTIFIER
  3112.     PARAMETERS { }
  3113.     ATTRIBUTES { }
  3114.     DESCRIPTION
  3115.        "Banyan Vines Address Resolution Protocol."
  3116.     REFERENCE
  3117.        "See vip."
  3118.     ::= { vip 0x04 }
  3119.  
  3120.  
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 53]
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132. Draft                  RMON Protocol Identifiers           November 1996
  3133.  
  3134.  
  3135. vipc PROTOCOL-IDENTIFIER
  3136.     PARAMETERS { }
  3137.     ATTRIBUTES {
  3138.         hasChildren(0)
  3139.     }
  3140.     DESCRIPTION
  3141.        "Banyan Vines Interprocess Communications Protocol."
  3142.     CHILDREN
  3143.        "Children of Vines IPC are identified by the packet type field at
  3144.        offset 4 in the vipc header.
  3145.  
  3146.        These are encoded as [ 0.0.0.a ] where 'a' is the packet type
  3147.        value.  Children of vipc are defined as 'vipc a' where 'a' is the
  3148.        packet type value in hexadecimal notation.
  3149.  
  3150.        The Vines Reliable Data Transport protocol is referred to as
  3151.        'vipc vipc-rdp' OR 'vipc 0x01'."
  3152.     DECODING
  3153.        "Children of vipc are deemed to start at the first byte after the
  3154.        packet type field (i.e. at offset 5 in the vipc header)."
  3155.     REFERENCE
  3156.        "See vip."
  3157.     ::= { vip 0x01 }
  3158.  
  3159. -- Banyan treat vipc, vipc-dgp and vipc-rdp as one protocol, IPC.
  3160. -- Vines IPC really comes in two flavours.  The first is used to
  3161. -- send unreliable datagrams (vipc packet type 0x00).  The second is used
  3162. -- to send reliable datagrams (vipc packet type 0x01),
  3163. -- consisting of up to four actual packets.
  3164. -- In order to distinguish between these we need two "virtual" protocols
  3165. -- to identify which is which.
  3166.  
  3167.  
  3168. vipc-dgp PROTOCOL-IDENTIFIER
  3169.     PARAMETERS { }
  3170.     ATTRIBUTES {
  3171.         hasChildren(0)
  3172.      }
  3173.     DESCRIPTION
  3174.        "Vines Unreliable Datagram Protocol."
  3175.     CHILDREN
  3176.        "Children of vipc-dgp are identified by the 16 bit port numbers
  3177.        contained in the vipc (this protocol's parent protocol) header.
  3178.  
  3179.        These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
  3180.  
  3181.  
  3182.  
  3183.  
  3184.  
  3185. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 54]
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191. Draft                  RMON Protocol Identifiers           November 1996
  3192.  
  3193.  
  3194.        the MSB of the port number in network byte order.
  3195.  
  3196.        Children of vipc-dgp are defined as 'vipc-dgp a' where 'a' is the
  3197.        port number in hexadecimal notation.
  3198.  
  3199.        The StreetTalk protocol running over vipc-dgp would be referred
  3200.        to as 'vipc-dgp streettalk' OR 'vipc-dgp 0x000F'.
  3201.  
  3202.        The mechanism by which an implementation selects which of the
  3203.        source and destination ports to use in determining which child
  3204.        protocol is present is implementation specific and beyond the
  3205.        scope of this document."
  3206.     DECODING
  3207.        "Children of vipc-dgp are deemed to start after the single
  3208.        padding byte found in the vipc header.  In the case of vipc-dgp
  3209.        the vipc header is a so called 'short' header, total length 6
  3210.        bytes (including the final padding byte)."
  3211.     REFERENCE
  3212.          "See vip."
  3213.     ::= { vipc 0x00 }
  3214.  
  3215.  
  3216. vipc-rdp PROTOCOL-IDENTIFIER
  3217.     PARAMETERS {
  3218.         countsFragments(0)
  3219.     }
  3220.     ATTRIBUTES {
  3221.         hasChildren(0)
  3222.     }
  3223.     DESCRIPTION
  3224.        "Vines Reliable Datagram Protocol."
  3225.     CHILDREN
  3226.        "Children of vipc-rdp are identified by the 16 bit port numbers
  3227.        contained in the vipc (this protocol's parent protocol) header.
  3228.  
  3229.        These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
  3230.        the MSB of the port number in network byte order.
  3231.  
  3232.        Children of vipc-dgp are defined as 'vipc-rdp a' where 'a' is the
  3233.        port number in hexadecimal notation.
  3234.  
  3235.        The StreetTalk protocol running over vipc-rdp would be referred
  3236.        to as 'vipc-rdp streettalk' OR 'vipc-rdp 0x000F'.
  3237.  
  3238.        The mechanism by which an implementation selects which of the
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 55]
  3245.  
  3246.  
  3247.  
  3248.  
  3249.  
  3250. Draft                  RMON Protocol Identifiers           November 1996
  3251.  
  3252.  
  3253.        source and destination ports to use in determining which child
  3254.        protocol is present is implementation specific and beyond the
  3255.        scope of this document."
  3256.     DECODING
  3257.        "Children of vipc-rdp are deemed to start after the error/length
  3258.        field at the end of the vipc header.  For vipc-rdp the vipc
  3259.        header is a so called 'long' header, total 16 bytes (including
  3260.        the final error/length field).
  3261.  
  3262.        vipc-rdp includes a high level fragmentation scheme which allows
  3263.        up to four vipc packets to be sent as a single atomic PDU.  The
  3264.        countsFragments(0) PARAMETERS bit indicates whether the probe can
  3265.        (and should) identify the child protocol in all fragments or only
  3266.        the leading one."
  3267.     REFERENCE
  3268.        "See vip."
  3269.     ::= { vipc 0x00 }
  3270.  
  3271.  
  3272. vspp PROTOCOL-IDENTIFIER
  3273.     PARAMETERS { }
  3274.     ATTRIBUTES {
  3275.         hasChildren(0)
  3276.     }
  3277.     DESCRIPTION
  3278.          "Banyan Vines Sequenced Packet Protocol."
  3279.     CHILDREN
  3280.        "Children of vspp are identified by the 16 bit port numbers
  3281.        contained in the vspp header.
  3282.  
  3283.        These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
  3284.        the MSB of the port number in network byte order.
  3285.  
  3286.        Children of vspp are defined as 'vspp a' where 'a' is the port
  3287.        number in hexadecimal notation.
  3288.  
  3289.        The StreetTalk protocol running over vspp would be referred to as
  3290.        'vspp streettalk' OR 'vspp 0x000F'.
  3291.  
  3292.        The mechanism by which an implementation selects which of the
  3293.        source and destination ports to use in determining which child
  3294.        protocol is present is implementation specific and beyond the
  3295.        scope of this document."
  3296.     DECODING
  3297.        "The implementation must ensure only those vspp packets which
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 56]
  3304.  
  3305.  
  3306.  
  3307.  
  3308.  
  3309. Draft                  RMON Protocol Identifiers           November 1996
  3310.  
  3311.  
  3312.        contain application data are decoded and passed on to children.
  3313.        Although it is suggested that the packet type and control fields
  3314.        should be used to determine this fact it is beyond the scope of
  3315.        this document to fully define the algorithm used."
  3316.     REFERENCE
  3317.        "See vip."
  3318.     ::= { vip 0x02 }
  3319.  
  3320.  
  3321. vrtp PROTOCOL-IDENTIFIER
  3322.     PARAMETERS { }
  3323.     ATTRIBUTES { }
  3324.     DESCRIPTION
  3325.        "Banyan Vines Routing Update Protocol."
  3326.     REFERENCE
  3327.        "See vip."
  3328.     ::= { vip 0x05 }
  3329.  
  3330.  
  3331. vicp PROTOCOL-IDENTIFIER
  3332.     PARAMETERS { }
  3333.     ATTRIBUTES { }
  3334.     DESCRIPTION
  3335.        "Banyan Vines Internet Control Protocol."
  3336.     REFERENCE
  3337.        "See vip."
  3338.     ::= { vip 0x06 }
  3339.  
  3340.        -- [ed. - We have two choices how we do vines apps. -- (1) The
  3341.        SUNRPC portmapper model. -- This has to be the preferred way to
  3342.        define all NetRPC based programs, -- i.e. by NetRPC program
  3343.        number. -- (2) Really ignore NetRPC as there is no -- good way to
  3344.        include it.  Instead define NetRPC protocols as children -- of
  3345.        vipc-rdp by port number.  Works for well-known ones but dynamic
  3346.        -- port numbers are used and NetRPC has a way of propagating
  3347.        these -- (StreetTalk??).
  3348.  
  3349.        -- So, if there is a portmapper-like program with a well known
  3350.        port number -- we should define it as a child of vipc-rdp (and
  3351.        vipc-dgp I suspect) and -- then declare all NetRPC based
  3352.        applications as children of this node by -- program number.  Use
  3353.        tracksSessions on the port mapper node to show that -- you need
  3354.        to do this in order to follow the RPC sessions.]
  3355.  
  3356.  
  3357.  
  3358.  
  3359.  
  3360.  
  3361.  
  3362. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 57]
  3363.  
  3364.  
  3365.  
  3366.  
  3367.  
  3368. Draft                  RMON Protocol Identifiers           November 1996
  3369.  
  3370.  
  3371. 5.3.6.  The DECNet Protocol Stack
  3372.  
  3373. lat PROTOCOL-IDENTIFIER
  3374.     PARAMETERS { }
  3375.     ATTRIBUTES { } -- Should have children but I don't know how.
  3376.     DESCRIPTION
  3377.        "DEC Local Area Transport Protocol."
  3378.     REFERENCE
  3379.        "[TBD]"
  3380.     ::= { ether2 0x6004 }
  3381.  
  3382.  
  3383. mop PROTOCOL-IDENTIFIER
  3384.     PARAMETERS { }
  3385.     ATTRIBUTES { }
  3386.     DESCRIPTION
  3387.        "DEC Maintainance Operations Protocol."
  3388.     REFERENCE
  3389.        "[TBD]"
  3390.     ::= {
  3391.         ether2 0x6001 -- mop dump/load
  3392.         ether2 0x6002 -- mop remote console
  3393.     }
  3394.  
  3395.  
  3396. dec-diag PROTOCOL-IDENTIFIER
  3397.     PARAMETERS { }
  3398.     ATTRIBUTES { }
  3399.     DESCRIPTION
  3400.        "DEC Diagnostic Protocol."
  3401.     REFERENCE
  3402.        "[TBD]"
  3403.     ::= { ether2 0x6005 }
  3404.  
  3405.  
  3406. lavc PROTOCOL-IDENTIFIER
  3407.     PARAMETERS { }
  3408.     ATTRIBUTES { }
  3409.     DESCRIPTION
  3410.        "DEC Local Area VAX Cluster Protocol."
  3411.     REFERENCE
  3412.        "[TBD]"
  3413.     ::= { ether2 0x6007 }
  3414.  
  3415.  
  3416.  
  3417.  
  3418.  
  3419.  
  3420.  
  3421. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 58]
  3422.  
  3423.  
  3424.  
  3425.  
  3426.  
  3427. Draft                  RMON Protocol Identifiers           November 1996
  3428.  
  3429.  
  3430. drp PROTOCOL-IDENTIFIER
  3431.     PARAMETERS {
  3432.         countsFragments(1)
  3433.     }
  3434.     ATTRIBUTES {
  3435.         hasChildren(0),
  3436.         addressRecognitionCapable(1)
  3437.     }
  3438.     DESCRIPTION
  3439.        "DEC Routing Protocol."
  3440.     ADDRESS-FORMAT
  3441.        "There are three address formats used in DRP packets, 2-byte
  3442.        (short data packet and all control except ethernet endnode &
  3443.        router hello messages), 6-byte (ethernet router & endnode hello
  3444.        messages) and 8-byte (long data packet).  All of these contain
  3445.        the 2-byte format address in the last 2 bytes with the remaining
  3446.        bytes being unimportant for the purposes of system
  3447.        identification.  It is beyond the scope of this document to
  3448.        define the algorithms used to identify packet types and hence
  3449.        address formats.
  3450.  
  3451.        The 2-byte address format is the concatenation of a 6-bit area
  3452.        and a 10-bit node number.  In all cases this is placed in little
  3453.        endian format (i.e. LSB, MSB).  The probe, however, will return
  3454.        them in network order (MSB, LSB).  For example area=13 (001101)
  3455.        and node=311 (0100110111) gives:
  3456.          0011 0101 0011 0111 = 0x3537 in network order (the order the
  3457.          probe should return the address in).
  3458.  
  3459.          In packets this same value would appear as (hex):
  3460.  
  3461.           2-byte  37 35
  3462.           6-byte  AA 00 04 00 37 35
  3463.           8-byte  00 00 AA 00 04 00 37 35
  3464.  
  3465.        Notice that the AA 00 04 00 prefix is defined in the
  3466.        specification but is unimportant and should not be parsed.
  3467.  
  3468.        Notice that control messages only have a source address in the
  3469.        header and so they can never be added into the conversation based
  3470.        tables."
  3471.     CHILDREN
  3472.        "There is only one child of DRP, NSP.  This is encoded as [
  3473.        0.0.0.1 ]."
  3474.     DECODING
  3475.  
  3476.  
  3477.  
  3478.  
  3479.  
  3480. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 59]
  3481.  
  3482.  
  3483.  
  3484.  
  3485.  
  3486. Draft                  RMON Protocol Identifiers           November 1996
  3487.  
  3488.  
  3489.        "NSP runs over DRP data packets; all other packet types are DRP
  3490.        control packets of one sort or another and do not carry any
  3491.        higher layer protocol.
  3492.  
  3493.        NSP packets are deemed to start at the beginning of the DRP data
  3494.        area.
  3495.  
  3496.        Data packets may be fragmented over multiple DRP data packets.
  3497.        The countsFragments(1) parameter indicates whether a probe can
  3498.        (and should) attribute non-leading fragments to the child
  3499.        protocol (above NSP in this case) or not.
  3500.  
  3501.        Recognition of DRP data packets and fragments is beyond the scope
  3502.        of this document."
  3503.     REFERENCE
  3504.        "DECnet Digital Network Architecture
  3505.          Phase IV
  3506.          Routing Layer Functional Specification
  3507.          Order# AA-X435A-TK
  3508.          Digital Equipment Corporation, Maynard, Massachusetts, USA"
  3509.     ::= {
  3510.         ether2  0x6003,
  3511.         snap    0x6003
  3512.     }
  3513.  
  3514.  
  3515. nsp PROTOCOL-IDENTIFIER
  3516.     PARAMETERS {
  3517.         tracksSessions(1)
  3518.     }
  3519.     ATTRIBUTES {
  3520.         hasChildren(0)
  3521.     }
  3522.     DESCRIPTION
  3523.        "DEC Network Services Protocol."
  3524.     CHILDREN
  3525.        "Children of NSP are identified by the SCP 8-bit object type.
  3526.        Notice that the object type is included only in the session
  3527.        establishment messages (connect initiate, retransmitted connect
  3528.        initiate).
  3529.  
  3530.        Children of NSP are encoded [ 0.0.0.a ] where 'a' is the SCP
  3531.        object type.  Children of NSP are named as 'nsp' followed by the
  3532.        SCP object type in decimal.  CTERM is referred to as 'nsp cterm'
  3533.        OR 'nsp 42'."
  3534.  
  3535.  
  3536.  
  3537.  
  3538.  
  3539. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 60]
  3540.  
  3541.  
  3542.  
  3543.  
  3544.  
  3545. Draft                  RMON Protocol Identifiers           November 1996
  3546.  
  3547.  
  3548.     DECODING
  3549.        "An implementation is encouraged to examine SCP headers included
  3550.        in NSP control messages in order to determine which child
  3551.        protocol is present over a given session.  It is beyond the scope
  3552.        of this document to define the algorithm used to do this.
  3553.  
  3554.        The tracksSessions(1) flag indicates whether the probe can (and
  3555.        should) perform this analysis."
  3556.     REFERENCE
  3557.        "DECnet Digital Network Architecture
  3558.          Phase IV
  3559.          NSP Functional Specification
  3560.          Order# AA-X439A-TK
  3561.          Digital Equipment Corporation, Maynard, Massachusetts, USA"
  3562.     ::= { drp 1 }
  3563.  
  3564.  
  3565. dap-v1 PROTOCOL-IDENTIFIER
  3566.     PARAMETERS { }
  3567.     ATTRIBUTES { }
  3568.     DESCRIPTION
  3569.        "DEC Data Access Protocol version 1."
  3570.     REFERENCE
  3571.        "[TBD]"
  3572.     ::= { nsp 1 }
  3573.  
  3574.  
  3575. dap-v4 PROTOCOL-IDENTIFIER
  3576.     PARAMETERS { }
  3577.     ATTRIBUTES { }
  3578.     DESCRIPTION
  3579.        "DEC Data Access Protocol versions 4 and above."
  3580.     REFERENCE
  3581.        "[TBD]"
  3582.     ::= { nsp 17 }
  3583.  
  3584.  
  3585. nice PROTOCOL-IDENTIFIER
  3586.     PARAMETERS { }
  3587.     ATTRIBUTES { }
  3588.     DESCRIPTION
  3589.        "DEC Network Information and Control Exchange protocol."
  3590.     REFERENCE
  3591.        "[TBD]"
  3592.     ::= { nsp 19 }
  3593.  
  3594.  
  3595.  
  3596.  
  3597.  
  3598. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 61]
  3599.  
  3600.  
  3601.  
  3602.  
  3603.  
  3604. Draft                  RMON Protocol Identifiers           November 1996
  3605.  
  3606.  
  3607. dec-loop PROTOCOL-IDENTIFIER
  3608.     PARAMETERS { }
  3609.     ATTRIBUTES { }
  3610.     DESCRIPTION
  3611.        "DEC Loopback Protocol."
  3612.     REFERENCE
  3613.        "[TBD]"
  3614.     ::= { nsp 25 }
  3615.  
  3616.  
  3617. dec-event PROTOCOL-IDENTIFIER
  3618.     PARAMETERS { }
  3619.     ATTRIBUTES { }
  3620.     DESCRIPTION
  3621.        "DEC Event Protocol."
  3622.     REFERENCE
  3623.        "[TBD]"
  3624.     ::= { nsp 26 }
  3625.  
  3626.  
  3627. cterm PROTOCOL-IDENTIFIER
  3628.     PARAMETERS { }
  3629.     ATTRIBUTES { }
  3630.     DESCRIPTION
  3631.        "DEC CTERM Protocol."
  3632.     REFERENCE
  3633.        "[TBD]"
  3634.     ::= { nsp 42 }
  3635.  
  3636.  
  3637.  
  3638. 5.3.7.  The IBM SNA Protocol Stack.
  3639.  
  3640. sna-th PROTOCOL-IDENTIFIER
  3641.     PARAMETERS { }
  3642.     ATTRIBUTES { }
  3643.       -- [ed. - clearly this really does have children, but I have
  3644.       -- no idea what applications are at the top, so is it
  3645.       -- worth expanding the hierarchy?]
  3646.     DESCRIPTION
  3647.        "IBM's SNA TH protocol."
  3648.     REFERENCE
  3649.        "IBM Systems Network Architecture
  3650.          Format and Protocol
  3651.          Reference Manual: Architectural Logic
  3652.  
  3653.  
  3654.  
  3655.  
  3656.  
  3657. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 62]
  3658.  
  3659.  
  3660.  
  3661.  
  3662.  
  3663. Draft                  RMON Protocol Identifiers           November 1996
  3664.  
  3665.  
  3666.          SC30-3112-2
  3667.  
  3668.          IBM System Communications Division,
  3669.          Publications Development,
  3670.          Department E02,
  3671.          PO Box 12195,
  3672.          Research Triangle Park,
  3673.          North Carolina 27709."
  3674.     ::= {
  3675.         llc 0x04,
  3676.         llc 0x08,
  3677.         llc 0x0c
  3678.     }
  3679.  
  3680.  
  3681.  
  3682. 5.3.8.  The NetBEUI/NetBIOS Family
  3683.  
  3684. -- [ed. this comment needs fixing
  3685. -- CHILDREN OF NETBIOS
  3686. -- The NetBIOS/NetBEUI functions are implemented over a wide variety of
  3687. -- transports.  Despite varying implementations they all share two
  3688. -- features.  Firstly all sessions are established by connecting to
  3689. -- locally named services.  Secondly all sessions transport application
  3690. -- between the client and the named service.  In all cases the
  3691. -- identification of the application protocol carried within the data
  3692. -- packets is beyond the scope of this document.]
  3693. --
  3694. -- Children of NetBIOS/NetBEUI are identified by the following (32 bit)
  3695. -- enumeration
  3696. --
  3697. --      1   smb (Microsoft's Server Message Block Protocol)
  3698. --      2   notes (Lotus' Notes Protocol)
  3699. --      3   cc-mail (Lotus' CC Mail Protocol)
  3700. --
  3701. -- Children of NetBIOS/NetBEUI are encoded as [ a.b.c.d ] where 'a', 'b',
  3702. -- 'c' and 'd' are the four octets of the enumerated value in network
  3703. -- order (i.e.  'a' is the MSB and 'd' is the LSB).
  3704. --
  3705. -- For example notes over NetBEUI is declared as
  3706. --      'notes ::= { netbeui 2 }'
  3707. -- but is referred to as
  3708. --      'netbeui notes' OR 'netbeui 2'.
  3709.  
  3710.  
  3711.  
  3712.  
  3713.  
  3714.  
  3715.  
  3716. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 63]
  3717.  
  3718.  
  3719.  
  3720.  
  3721.  
  3722. Draft                  RMON Protocol Identifiers           November 1996
  3723.  
  3724.  
  3725. netbeui PROTOCOL-IDENTIFIER
  3726.     PARAMETERS {
  3727.         tracksSessions(1)
  3728.     }
  3729.     ATTRIBUTES {
  3730.         hasChildren(0)
  3731.     }
  3732.     DESCRIPTION
  3733.        "Lan Manager NetBEUI protocol."
  3734.     CHILDREN
  3735.        "See `CHILDREN OF NETBIOS`"
  3736.     DECODING
  3737.        "NETBEUI provides a named service lookup function.  This function
  3738.        allows clients to locate a service by (locally assigned) name. An
  3739.        implementation is encouraged to follow lookups and session
  3740.        establishments and having determined the child protocol, track
  3741.        them.
  3742.  
  3743.        How the child protocol is determined and how the sessions are
  3744.        tracked is an implementation specific matter and is beyond the
  3745.        scope of this document."
  3746.     REFERENCE
  3747.        "[TBD]"
  3748.     ::= { llc 0xFO }
  3749.  
  3750.  
  3751. nbt-name PROTOCOL-IDENTIFIER
  3752.     PARAMETERS { }
  3753.     ATTRIBUTES { }
  3754.     DESCRIPTION
  3755.        "NetBIOS-over-TCP name protocol."
  3756.     REFERENCE
  3757.        "[TBD]"
  3758.     ::= {
  3759.         udp     137,
  3760.         tcp     137
  3761.     }
  3762.  
  3763.  
  3764. nbt-session PROTOCOL-IDENTIFIER
  3765.     PARAMETERS { }
  3766.     ATTRIBUTES { }
  3767.     DESCRIPTION
  3768.        "NetBIOS-over-TCP session protocol."
  3769.     REFERENCE
  3770.  
  3771.  
  3772.  
  3773.  
  3774.  
  3775. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 64]
  3776.  
  3777.  
  3778.  
  3779.  
  3780.  
  3781. Draft                  RMON Protocol Identifiers           November 1996
  3782.  
  3783.  
  3784.        "[TBD]"
  3785.     ::= {
  3786.         udp     139,
  3787.         tcp     139
  3788.     }
  3789.  
  3790.  
  3791. nbt-data PROTOCOL-IDENTIFIER
  3792.     PARAMETERS { }
  3793.     ATTRIBUTES {
  3794.         hasChildren(0)
  3795.     }
  3796.     DESCRIPTION
  3797.        "NetBIOS-over-TCP datagram protocol."
  3798.     CHILDREN
  3799.        "See `CHILDREN OF NETBIOS`"
  3800.     REFERENCE
  3801.        "[TBD]"
  3802.     ::= {
  3803.         udp     138,
  3804.         tcp     138
  3805.     }
  3806.  
  3807.  
  3808. netbios-3com PROTOCOL-IDENTIFIER
  3809.     PARAMETERS { }
  3810.     ATTRIBUTES {
  3811.         hasChildren(0)
  3812.     }
  3813.     DESCRIPTION
  3814.        "3COM NetBIOS protocol."
  3815.     CHILDREN
  3816.        "See `CHILDREN OF NETBIOS`"
  3817.     REFERENCE
  3818.        "[TBD]"
  3819.     ::= {
  3820.         ether2  0x3C00,
  3821.         ether2  0x3C01,
  3822.         ether2  0x3C02,
  3823.         ether2  0x3C03,
  3824.         ether2  0x3C04,
  3825.         ether2  0x3C05,
  3826.         ether2  0x3C06,
  3827.         ether2  0x3C07,
  3828.         ether2  0x3C08,
  3829.  
  3830.  
  3831.  
  3832.  
  3833.  
  3834. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 65]
  3835.  
  3836.  
  3837.  
  3838.  
  3839.  
  3840. Draft                  RMON Protocol Identifiers           November 1996
  3841.  
  3842.  
  3843.         ether2  0x3C09,
  3844.         ether2  0x3C0A,
  3845.         ether2  0x3C0B,
  3846.         ether2  0x3C0C,
  3847.         ether2  0x3C0D
  3848.     }
  3849.  
  3850.  
  3851. nov-netbios PROTOCOL-IDENTIFIER
  3852.     PARAMETERS { }
  3853.     ATTRIBUTES {
  3854.         hasChildren(0)
  3855.     }
  3856.     DESCRIPTION
  3857.        "Novell's version of the NetBIOS protocol."
  3858.     CHILDREN
  3859.        "See `CHILDREN OF NETBIOS`"
  3860.     REFERENCE
  3861.        "[TBD]"
  3862.     ::= {
  3863.         nov-sap 0x0020 -- this is the right one to use
  3864.         -- these are typically also true, but derivable from the one
  3865.         -- above at run-time
  3866.         -- ipx  0x14 -- when reached by IPX packet type
  3867.         -- nov-pep 0x0455 -- when reached by socket number
  3868.     }
  3869.  
  3870.  
  3871. 5.4.  Multi-stack protocols
  3872.  
  3873. smb PROTOCOL-IDENTIFIER
  3874.     PARAMETERS { }
  3875.     ATTRIBUTES { }
  3876.     DESCRIPTION
  3877.        "Microsoft Server Message Block Protocol."
  3878.     REFERENCE
  3879.        "[TBD]"
  3880.     ::= {
  3881.         netbeui         1,
  3882.         netbios-3com    1,
  3883.         nov-netbios     1,
  3884.         nbt-data        1,
  3885.         -- nov-spx ???, -- Microsoft run it over a well-known SPX socket?
  3886.         -- vspp ???,
  3887.         -- xns-spp ???
  3888.  
  3889.  
  3890.  
  3891.  
  3892.  
  3893. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 66]
  3894.  
  3895.  
  3896.  
  3897.  
  3898.  
  3899. Draft                  RMON Protocol Identifiers           November 1996
  3900.  
  3901.  
  3902.     }
  3903.  
  3904.  
  3905. notes PROTOCOL-IDENTIFIER
  3906.     PARAMETERS { }
  3907.     ATTRIBUTES { }
  3908.     DESCRIPTION
  3909.        "Lotus Notes Protocol."
  3910.     REFERENCE
  3911.        "[TBD]"
  3912.     ::= {
  3913.         netbeui         2,
  3914.         netbios-3com    2,
  3915.         nov-netbios     2,
  3916.         nbt-data        2,
  3917.         tcp             1352,
  3918.         udp             1352
  3919.     }
  3920.  
  3921.  
  3922. ccmail PROTOCOL-IDENTIFIER
  3923.     PARAMETERS { }
  3924.     ATTRIBUTES { }
  3925.     DESCRIPTION
  3926.          "Lotus CC-mail Protocol."
  3927.     REFERENCE
  3928.        "[TBD]"
  3929.     ::= {
  3930.         netbeui         3,
  3931.         netbios-3com    3,
  3932.         nov-netbios     3,
  3933.         nbt-data        3,
  3934.         tcp             3264,
  3935.         udp             3264
  3936.     }
  3937.  
  3938.  
  3939. snmp  PROTOCOL-IDENTIFIER
  3940.     PARAMETERS { }
  3941.     ATTRIBUTES { }
  3942.     DESCRIPTION
  3943.        "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
  3944.        protocol versions. Does not include SNMP trap packets."
  3945.     REFERENCE
  3946.        "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
  3947.  
  3948.  
  3949.  
  3950.  
  3951.  
  3952. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 67]
  3953.  
  3954.  
  3955.  
  3956.  
  3957.  
  3958. Draft                  RMON Protocol Identifiers           November 1996
  3959.  
  3960.  
  3961.        protocol is defined in RFC 1905 [RFC1905].  Transport mappings
  3962.        are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
  3963.        [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
  3964.     ::= {
  3965.         udp 161,
  3966.         ipx 0x900f,   -- [ 0.0.144.15 ]
  3967.         atalk 8
  3968.     }
  3969.  
  3970.  
  3971. snmptrap PROTOCOL-IDENTIFIER
  3972.     PARAMETERS { }
  3973.     ATTRIBUTES { }
  3974.     DESCRIPTION
  3975.        "Simple Network Management Protocol Trap Port."
  3976.     REFERENCE
  3977.        "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
  3978.        protocol is defined in RFC 1905 [RFC1905].  Transport mappings
  3979.        are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
  3980.        [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
  3981.     ::= {
  3982.         udp 162,
  3983.         ipx 0x9010,
  3984.         atalk 9
  3985.     }
  3986.  
  3987. -- END
  3988.  
  3989.  
  3990. 6.  Acknowledgements
  3991.  
  3992. This document was produced by the IETF RMONMIB Working Group.
  3993.  
  3994. The authors wish to thank the following people for their contributions
  3995. to this document:
  3996.  
  3997.      Anil Singhal
  3998.      Frontier Software Development, Inc.
  3999.  
  4000.      Jeanne Haney
  4001.      Bay Networks
  4002.  
  4003.      Dan Hansen
  4004.      Network General Corp.
  4005.  
  4006.  
  4007.  
  4008.  
  4009.  
  4010.  
  4011. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 68]
  4012.  
  4013.  
  4014.  
  4015.  
  4016.  
  4017. Draft                  RMON Protocol Identifiers           November 1996
  4018.  
  4019.  
  4020. 7.  References
  4021.  
  4022. [RFC768]
  4023.      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  4024.      USC/Information Sciences Institute, August 1980.
  4025.  
  4026. [RFC791]
  4027.      Postel, J., ed., "Internet Protocol - DARPA Internet Program
  4028.      Protocol Specification", STD 5, RFC 791, USC/Information Sciences
  4029.      Institute, September 1981.
  4030.  
  4031. [RFC792]
  4032.      Postel, J., "Internet Control Message Protocol - DARPA Internet
  4033.      Program Protocol Specification", STD 5, RFC 792, USC/Information
  4034.      Sciences Institute, September 1981.
  4035.  
  4036. [RFC793]
  4037.      Postel, J., "Transmission Control Protocol - DARPA Internet Program
  4038.      Protocol Specification", STD 5, RFC 793, USC/Information Sciences
  4039.      Institute, September 1981.
  4040.  
  4041. [RFC821]
  4042.      Postel, J., "Simple Mail Transfer Protocol", RFC 821,
  4043.      USC/Information Sciences Institute, August 1982.
  4044.  
  4045. [RFC826]
  4046.      Plummer, D., "An Ethernet Address Resolution Protocol or
  4047.      "Converting Network Protocol Addresses to 48-bit Ethernet Addresses
  4048.      for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS,
  4049.      November 1982.
  4050.  
  4051. [RFC854]
  4052.      Postel, J. and Reynolds, J., "Telnet Protocol Specification", RFC
  4053.      854, ISI, May 1983.
  4054.  
  4055. [RFC894]
  4056.      C.OHornig, "A Standard for the Transmission of IP Datagrams over
  4057.      Ethernet Networks", RFC 894, Symbolics, April 1984.
  4058.  
  4059. [RFC951]
  4060.      Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
  4061.      Stanford and SUN Microsytems, September 1985.
  4062.  
  4063. [RFC959]
  4064.      Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
  4065.  
  4066.  
  4067.  
  4068.  
  4069.  
  4070. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 69]
  4071.  
  4072.  
  4073.  
  4074.  
  4075.  
  4076. Draft                  RMON Protocol Identifiers           November 1996
  4077.  
  4078.  
  4079.      USC/Information Sciences Institute, October 1985.
  4080.  
  4081. [RFC1035]
  4082.      Mockapetris, P., "Domain Names - Implementation and Specification",
  4083.      STD 13, RFC 1035, USC/Information Sciences Institute, November
  4084.      1987.
  4085.  
  4086. [RFC1157]
  4087.      Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
  4088.      Management Protocol", RFC 1157, SNMP Research, Performance Systems
  4089.      International, MIT Laboratory for Computer Science, May 1990.
  4090.  
  4091. [RFC1213]
  4092.      McCloghrie, K., and M. Rose, Editors, "Management Information Base
  4093.      for Network Management of TCP/IP-based internets: MIB-II", STD 17,
  4094.      RFC 1213, Hughes LAN Systems, Performance Systems International,
  4095.      March 1991.
  4096.  
  4097. [RFC1350]
  4098.      Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
  4099.      1992.
  4100.  
  4101. [RFC1419]
  4102.      Minshall, G., and M.  Ritter, "SNMP over AppleTalk", RFC 1419,
  4103.      Novell, Inc., Apple Computer, Inc., March 1993.
  4104.  
  4105. [RFC1420]
  4106.      Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
  4107.  
  4108. [RFC1700]
  4109.      Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  4110.      USC/Information Sciences Institute, October 1994.
  4111.  
  4112. [RFC1725]
  4113.      Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
  4114.      1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
  4115.  
  4116. [RFC1757]
  4117.      S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
  4118.      Mellon University, February 1995.
  4119.  
  4120. [RFC1782]
  4121.      Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782,
  4122.      Xylogics, Inc., Hewlett Packard Co., March 1995.
  4123.  
  4124.  
  4125.  
  4126.  
  4127.  
  4128.  
  4129. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 70]
  4130.  
  4131.  
  4132.  
  4133.  
  4134.  
  4135. Draft                  RMON Protocol Identifiers           November 1996
  4136.  
  4137.  
  4138. [RFC1783]
  4139.      Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783,
  4140.      Xylogics, Inc., Hewlett Packard Co., March 1995.
  4141.  
  4142. [RFC1784]
  4143.      Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
  4144.      Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
  4145.      1995.
  4146.  
  4147. [RFC1800]
  4148.      Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
  4149.      RFC 1800, IAB, July 1995.
  4150.  
  4151. [RFC1831]
  4152.      Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
  4153.      1831, Sun Microsystems, Inc., August 1995.
  4154.  
  4155. [RFC1902]
  4156.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  4157.      S. Waldbusser, "Structure of Management Information for version 2
  4158.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  4159.      January 1996.
  4160.  
  4161. [RFC1903]
  4162.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  4163.      S. Waldbusser, "Textual Conventions for version 2 of the Simple
  4164.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  4165.  
  4166. [RFC1904]
  4167.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  4168.      S. Waldbusser, "Conformance Statements for version 2 of the Simple
  4169.      Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
  4170.  
  4171. [RFC1905]
  4172.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  4173.      S. Waldbusser, "Protocol Operations for version 2 of the Simple
  4174.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  4175.  
  4176. [RFC1906]
  4177.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
  4178.      Waldbusser, "Transport Mappings for Version 2 of the Simple Network
  4179.      Management Protocol (SNMPv2)", RFC 1906, January 1996.
  4180.  
  4181. [RFC1945]
  4182.      Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
  4183.  
  4184.  
  4185.  
  4186.  
  4187.  
  4188. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 71]
  4189.  
  4190.  
  4191.  
  4192.  
  4193.  
  4194. Draft                  RMON Protocol Identifiers           November 1996
  4195.  
  4196.  
  4197.      HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995.
  4198.  
  4199. [RMON2]
  4200.      S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
  4201.      ietf-rmonmib-rmon2-03.txt, International Network Services, January
  4202.      1996.
  4203.  
  4204.  
  4205.  
  4206.  
  4207.  
  4208.  
  4209.  
  4210.  
  4211.  
  4212.  
  4213.  
  4214.  
  4215.  
  4216.  
  4217.  
  4218.  
  4219.  
  4220.  
  4221.  
  4222.  
  4223.  
  4224.  
  4225.  
  4226.  
  4227.  
  4228.  
  4229.  
  4230.  
  4231.  
  4232.  
  4233.  
  4234.  
  4235.  
  4236.  
  4237.  
  4238.  
  4239.  
  4240.  
  4241.  
  4242.  
  4243.  
  4244.  
  4245.  
  4246.  
  4247. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 72]
  4248.  
  4249.  
  4250.  
  4251.  
  4252.  
  4253. Draft                  RMON Protocol Identifiers           November 1996
  4254.  
  4255.  
  4256. 8.  Security Considerations
  4257.  
  4258. Security issues are not discussed in this memo.
  4259.  
  4260.  
  4261. 9.  Authors' Addresses
  4262.  
  4263.      Andy Bierman
  4264.      Cisco Systems, Inc.
  4265.      170 West Tasman Drive
  4266.      San Jose, CA 95134
  4267.      Phone: 408-527-3711
  4268.      Email: abierman@cisco.com
  4269.  
  4270.      Chris Bucci
  4271.      Network General Corporation
  4272.      [ed. - address and phone TBD]
  4273.      Email: buccic@ngc.com
  4274.  
  4275.      Robin Iddon
  4276.      3Com Inc.
  4277.      40/50 Blackfrias Street
  4278.      Edinburgh, UK
  4279.      Phone: +44 131.558.3888
  4280.      Email: Robin_Iddon@3mail.3com.com
  4281.  
  4282.  
  4283.  
  4284.  
  4285.  
  4286.  
  4287.  
  4288.  
  4289.  
  4290.  
  4291.  
  4292.  
  4293.  
  4294.  
  4295.  
  4296.  
  4297.  
  4298.  
  4299.  
  4300.  
  4301.  
  4302.  
  4303.  
  4304.  
  4305.  
  4306. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 73]
  4307.  
  4308.  
  4309.  
  4310.  
  4311.  
  4312. Draft                  RMON Protocol Identifiers           November 1996
  4313.  
  4314.  
  4315. Table of Contents
  4316.  
  4317.  
  4318. 1 Introduction ....................................................    2
  4319. 2 The SNMP Network Management Framework ...........................    3
  4320. 2.1 Object Definitions ............................................    3
  4321. 3 Overview ........................................................    4
  4322. 3.1 Terms .........................................................    4
  4323. 3.2 Relationship to the Remote Network Monitoring MIB .............    6
  4324. 3.3 Relationship to the Other MIBs ................................    6
  4325. 4 Protocol Identifier Encoding ....................................    7
  4326. 4.1 ProtocolDirTable INDEX Format Examples ........................   10
  4327. 4.2 Protocol Identifier Macro Format ..............................   10
  4328. 4.2.1 Mapping of the Protocol Name ................................   13
  4329. 4.2.2 Mapping of the VARIANT-OF Clause ............................   13
  4330. 4.2.3 Mapping of the PARAMETERS Clause ............................   14
  4331. 4.2.3.1 Mapping of the 'countsFragments(0)' BIT ...................   15
  4332. 4.2.3.2 Mapping of the 'tracksSessions(1)' BIT ....................   15
  4333. 4.2.4 Mapping of the ATTRIBUTES Clause ............................   16
  4334. 4.2.5 Mapping of the DESCRIPTION Clause ...........................   17
  4335. 4.2.6 Mapping of the CHILDREN Clause ..............................   17
  4336. 4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................   18
  4337. 4.2.8 Mapping of the DECODING Clause ..............................   18
  4338. 4.2.9 Mapping of the REFERENCE Clause .............................   18
  4339. 4.3 Evaluating a Protocol-Identifier INDEX ........................   19
  4340. 5 Protocol Identifier Macros ......................................   20
  4341. 5.1 Base Identifier Encoding ......................................   20
  4342. 5.1.1 Protocol Identifier Functions ...............................   20
  4343. 5.1.1.1 Function 0: No-op .........................................   21
  4344. 5.1.1.2 Function 1: Protocol Wildcard Function ....................   21
  4345. 5.2 Base Layer Protocol Identifiers ...............................   22
  4346. 5.2.1 Ether2 Encapsulation ........................................   22
  4347. 5.2.2 LLC Encapsulation ...........................................   23
  4348. 5.2.3 SNAP over LLC (OUI=000) Encapsulation .......................   25
  4349. 5.2.4 SNAP over LLC (OUI != 000) Encapsulation ....................   26
  4350. 5.2.5 Working Group Assigned Protocols ............................   27
  4351. 5.2.5.1 Working Group Assigned Protocol Identifiers ...............   29
  4352. 5.3 Protocol Stacks And Single-Vendor Applications ................   29
  4353. 5.3.1 The TCP/IP protocol stack ...................................   30
  4354. 5.3.2 Novell IPX Stack ............................................   38
  4355. 5.3.3 The XEROX Protocol Stack ....................................   44
  4356. 5.3.4 AppleTalk Protocol Stack ....................................   47
  4357. 5.3.5 Banyon Vines Protocol Stack .................................   51
  4358. 5.3.6 The DECNet Protocol Stack ...................................   58
  4359. 5.3.7 The IBM SNA Protocol Stack.  ................................   62
  4360.  
  4361.  
  4362.  
  4363.  
  4364.  
  4365. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 74]
  4366.  
  4367.  
  4368.  
  4369.  
  4370.  
  4371. Draft                  RMON Protocol Identifiers           November 1996
  4372.  
  4373.  
  4374. 5.3.8 The NetBEUI/NetBIOS Family ..................................   63
  4375. 5.4 Multi-stack protocols .........................................   66
  4376. 6 Acknowledgements ................................................   68
  4377. 7 References ......................................................   69
  4378. 8 Security Considerations .........................................   73
  4379. 9 Authors' Addresses ..............................................   73
  4380.  
  4381.  
  4382.  
  4383.  
  4384.  
  4385.  
  4386.  
  4387.  
  4388.  
  4389.  
  4390.  
  4391.  
  4392.  
  4393.  
  4394.  
  4395.  
  4396.  
  4397.  
  4398.  
  4399.  
  4400.  
  4401.  
  4402.  
  4403.  
  4404.  
  4405.  
  4406.  
  4407.  
  4408.  
  4409.  
  4410.  
  4411.  
  4412.  
  4413.  
  4414.  
  4415.  
  4416.  
  4417.  
  4418.  
  4419.  
  4420.  
  4421.  
  4422.  
  4423.  
  4424. Bierman/Bucci/Iddon        Expires May, 1997                   [Page 75]
  4425.  
  4426.