home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2074.txt < prev    next >
Text File  |  1997-01-14  |  81KB  |  2,412 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       A. Bierman
  8. Request for Comments: 2074                               Cisco Systems
  9. Category: Standards Track                                     R. Iddon
  10.                                                     AXON Networks,Inc.
  11.                                                           January 1997
  12.  
  13.  
  14.            Remote Network Monitoring MIB Protocol Identifiers
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Table of Contents
  25.  
  26. 1 Introduction ....................................................    3
  27. 2 The SNMP Network Management Framework ...........................    3
  28. 2.1 Object Definitions ............................................    3
  29. 3 Overview ........................................................    3
  30. 3.1 Terms .........................................................    4
  31. 3.2 Relationship to the Remote Network Monitoring MIB .............    6
  32. 3.3 Relationship to the Other MIBs ................................    6
  33. 4 Protocol Identifier Encoding ....................................    7
  34. 4.1 ProtocolDirTable INDEX Format Examples ........................    9
  35. 4.2 Protocol Identifier Macro Format ..............................   10
  36. 4.2.1 Mapping of the Protocol Name ................................   12
  37. 4.2.2 Mapping of the VARIANT-OF Clause ............................   13
  38. 4.2.3 Mapping of the PARAMETERS Clause ............................   13
  39. 4.2.3.1 Mapping of the 'countsFragments(0)' BIT ...................   14
  40. 4.2.3.2 Mapping of the 'tracksSessions(1)' BIT ....................   15
  41. 4.2.4 Mapping of the ATTRIBUTES Clause ............................   15
  42. 4.2.5 Mapping of the DESCRIPTION Clause ...........................   15
  43. 4.2.6 Mapping of the CHILDREN Clause ..............................   16
  44. 4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................   16
  45. 4.2.8 Mapping of the DECODING Clause ..............................   16
  46. 4.2.9 Mapping of the REFERENCE Clause .............................   17
  47. 4.2.10 Evaluating a Protocol-Identifier INDEX .....................   17
  48. 5 Protocol Identifier Macros ......................................   18
  49. 5.1 Base Identifier Encoding ......................................   18
  50. 5.1.1 Protocol Identifier Functions ...............................   19
  51. 5.1.1.1 Function 0: No-op .........................................   19
  52. 5.1.1.2 Function 1: Protocol Wildcard Function ....................   19
  53. 5.2 Base Layer Protocol Identifiers ...............................   20
  54. 5.2.1 Ether2 Encapsulation ........................................   21
  55.  
  56.  
  57.  
  58. Bierman & Iddon             Standards Track                     [Page 1]
  59.  
  60. RFC 2074               RMON Protocol Identifiers            January 1997
  61.  
  62.  
  63. 5.2.2 LLC Encapsulation ...........................................   22
  64. 5.2.3 SNAP over LLC (OUI=000) Encapsulation .......................   23
  65. 5.2.4 SNAP over LLC (OUI != 000) Encapsulation ....................   24
  66. 5.2.5 IANA Assigned Protocols .....................................   25
  67. 5.2.5.1 IANA Assigned Protocol Identifiers ........................   27
  68. 5.3 L3: Children of Base Protocol Identifiers .....................   27
  69. 5.3.1 IP ..........................................................   28
  70. 5.3.2 IPX .........................................................   29
  71. 5.3.3 ARP .........................................................   30
  72. 5.3.4 IDP .........................................................   30
  73. 5.3.5 AppleTalk ARP ...............................................   31
  74. 5.3.6 AppleTalk ...................................................   31
  75. 5.4 L4: Children of L3 Protocols ..................................   32
  76. 5.4.1 ICMP ........................................................   32
  77. 5.4.2 TCP .........................................................   32
  78. 5.4.3 UDP .........................................................   33
  79. 5.5 L5: Application Layer Protocols ...............................   33
  80. 5.5.1 FTP .........................................................   33
  81. 5.5.1.1 FTP-DATA ..................................................   33
  82. 5.5.1.2 FTP Control ...............................................   34
  83. 5.5.2 Telnet ......................................................   34
  84. 5.5.3 SMTP ........................................................   34
  85. 5.5.4 DNS .........................................................   35
  86. 5.5.5 BOOTP .......................................................   35
  87. 5.5.5.1 Bootstrap Server Protocol .................................   35
  88. 5.5.5.2 Bootstrap Client Protocol .................................   35
  89. 5.5.6 TFTP ........................................................   36
  90. 5.5.7 HTTP ........................................................   36
  91. 5.5.8 POP3 ........................................................   36
  92. 5.5.9 SUNRPC ......................................................   37
  93. 5.5.10 NFS ........................................................   38
  94. 5.5.11 SNMP .......................................................   38
  95. 5.5.11.1 SNMP Request/Response ....................................   38
  96. 5.5.11.2 SNMP Trap ................................................   39
  97. 6 Acknowledgements ................................................   39
  98. 7 References ......................................................   40
  99. 8 Security Considerations .........................................   43
  100. 9 Authors' Addresses ..............................................   43
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Bierman & Iddon             Standards Track                     [Page 2]
  115.  
  116. RFC 2074               RMON Protocol Identifiers            January 1997
  117.  
  118.  
  119. 1.  Introduction
  120.  
  121.    This memo defines an experimental portion of the Management
  122.    Information Base (MIB) for use with network management protocols in
  123.    the Internet community.  In particular, it describes the algorithms
  124.    required to identify different protocol encapsulations managed with
  125.    the Remote Network Monitoring MIB Version 2 [RMON2]. Although related
  126.    to the original Remote Network Monitoring MIB [RFC1757], this
  127.    document refers only to objects found in the RMON-2 MIB.
  128.  
  129. 2.  The SNMP Network Management Framework
  130.  
  131.    The SNMP Network Management Framework presently consists of three
  132.    major components.  They are:
  133.  
  134. o    the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
  135.      describing and naming objects for the purpose of management.
  136.  
  137. o    the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
  138.      objects for the Internet suite of protocols.
  139.  
  140. o    the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905],
  141.      - the protocol for accessing managed information.
  142.  
  143.    Textual conventions are defined in RFC 1903 [RFC1903], and
  144.    conformance statements are defined in RFC 1904 [RFC1904].
  145.  
  146.    The Framework permits new objects to be defined for the purpose of
  147.    experimentation and evaluation.
  148.  
  149. 2.1.  Object Definitions
  150.  
  151.    Managed objects are accessed via a virtual information store, termed
  152.    the Management Information Base or MIB.  Objects in the MIB are
  153.    defined using the subset of Abstract Syntax Notation One (ASN.1)
  154.    defined in the SMI.  In particular, each object type is named by an
  155.    OBJECT IDENTIFIER, an administratively assigned name.  The object
  156.    type together with an object instance serves to uniquely identify a
  157.    specific instantiation of the object.  For human convenience, we
  158.    often use a textual string, termed the descriptor, to refer to the
  159.    object type.
  160.  
  161. 3.  Overview
  162.  
  163.    The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to
  164.    globally identify individual protocol encapsulations in the
  165.    protocolDirTable.
  166.  
  167.  
  168.  
  169.  
  170. Bierman & Iddon             Standards Track                     [Page 3]
  171.  
  172. RFC 2074               RMON Protocol Identifiers            January 1997
  173.  
  174.  
  175.    This guide contains algorithms and examples of protocol identifier
  176.    encapsulations for use as INDEX values in the protocolDirTable.
  177.  
  178.    This document is not intended to be an authoritative reference on the
  179.    protocols described herein. Refer to the Official Internet Standards
  180.    document [RFC1800], the Assigned Numbers document [RFC1700], or other
  181.    appropriate RFCs, IEEE documents, etc. for complete and authoritative
  182.    protocol information.
  183.  
  184. 3.1.  Terms
  185.  
  186.    Several terms are used throughout this document, as well as in the
  187.    RMON-2 MIB [RMON2], that should be introduced:
  188.  
  189. layer-identifier:
  190.      An octet string fragment representing a particular protocol
  191.      encapsulation layer. A string fragment identifying a particular
  192.      protocol encapsulation layer. This string is exactly four octets,
  193.      (except for the 'vsnap' base-layer identifier, which is exactly
  194.      eight octets) encoded in network byte order. A particular protocol
  195.      encapsulation can be identified by starting with a base layer
  196.      encapsulation (see the 'Base Protocol Identifiers' section for more
  197.      detail), and following the encoding rules specified in the CHILDREN
  198.      clause and assignment section for that layer. Then repeat for each
  199.      identified layer in the encapsulation. (See section 4.2.10
  200.      'Evaluating a Protocol-Identifier INDEX' for more detail.)
  201.  
  202. protocol:
  203.      A particular protocol layer, as specified by encoding rules in this
  204.      document. Usually refers to a single layer in a given
  205.      encapsulation. Note that this term is sometimes used in the RMON-2
  206.      MIB [RMON2] to name a fully-specified protocol-identifier string.
  207.      In such a case, the protocol-identifier string is named for its
  208.      upper-most layer. A named protocol may also refer to any
  209.      encapsulation of that protocol.
  210.  
  211. protocol-identifier string:
  212.      An octet string representing a particular protocol encapsulation,
  213.      as specified by encoding rules in this document. This string is
  214.      identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
  215.      protocol-identifier string is composed of one or more layer-
  216.      identifiers.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bierman & Iddon             Standards Track                     [Page 4]
  227.  
  228. RFC 2074               RMON Protocol Identifiers            January 1997
  229.  
  230.  
  231. protocol-identifier macro:
  232.      A group of formatted text describing a particular protocol layer,
  233.      as used within the RMON-2 MIB [RMON2]. The macro serves several
  234.      purposes:
  235.  
  236.      - Name the protocol for use within the RMON-2 MIB [RMON2].
  237.      - Describe how the protocol is encoded into an octet string.
  238.      - Describe how child protocols are identified (if applicable),
  239.        and encoded into an octet string.
  240.      - Describe which protocolDirParameters are allowed for the protocol.
  241.      - Describe how the associated protocolDirType object is encoded
  242.        for the protocol.
  243.      - Provide reference(s) to authoritative documentation for the
  244.        protocol.
  245.  
  246. protocol-variant-identifier macro:
  247.      A group of formatted text describing a particular protocol layer,
  248.      as used within the RMON-2 MIB [RMON2]. This protocol is a variant
  249.      of a well known encapsulation that may be present in the
  250.      protocolDirTable. This macro is used to document the IANA
  251.      assigned protocols, which are needed to identify protocols which
  252.      cannot be practically identified by examination of 'appropriate
  253.      network traffic' (e.g. the packets which carry them). All other
  254.      protocols (which can be identified by examination of appropriate
  255.      network traffic) should be documented using the protocol-identifier
  256.      macro. A protocol-variant-identifier is documented using the
  257.      protocol-variant version of the protocol-identifier macro.
  258.  
  259. protocol-parameter:
  260.      A single octet, corresponding to a specific layer-identifier in the
  261.      protocol-identifier. This octet is a bit-mask indicating special
  262.      functions or capabilities that this agent is providing for the
  263.      corresponding protocol.
  264.  
  265. protocol-parameters string:
  266.      An octet string, which contains one protocol-parameter for each
  267.      layer-identifier in the protocol-identifier.  See the section
  268.      'Mapping of the PARAMETERS Clause' for more detail.  This string is
  269.      identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
  270.      object.
  271.  
  272. protocolDirTable INDEX:
  273.      A protocol-identifier and protocol-parameters octet string pair
  274.      that have been converted to an INDEX value, according to the
  275.      encoding rules in in section 7.7 of RFC 1902 [RFC1902].
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Bierman & Iddon             Standards Track                     [Page 5]
  283.  
  284. RFC 2074               RMON Protocol Identifiers            January 1997
  285.  
  286.  
  287. pseudo-protocol:
  288.      A convention or algorithm used only within this document for the
  289.      purpose of encoding protocol-identifier strings.
  290.  
  291. 3.2.  Relationship to the Remote Network Monitoring MIB
  292.  
  293.    This document is intended to identify possible string values for the
  294.    OCTET STRING objects protocolDirID and protocolDirParameters.  Tables
  295.    in the new Protocol Distribution, Host, and Matrix groups use a local
  296.    INTEGER INDEX, in order to remain unaffected by changes in this
  297.    document. Only the protocolDirTable uses the strings (protocolDirID
  298.    and protocolDirParameters) described in this document.
  299.  
  300.    This document is not intended to limit the protocols that may be
  301.    identified for counting in the RMON-2 MIB. Many protocol
  302.    encapsulations, not explicitly identified in this document, may be
  303.    present in an actual implementation of the protocolDirTable. Also,
  304.    implementations of the protocolDirTable may not include all the
  305.    protocols identified in the example section below.
  306.  
  307.    This document is intentionally separated from the MIB objects to
  308.    allow frequent updates to this document without any republication of
  309.    MIB objects.  Protocol Identifier macros submitted from the RMON
  310.    working group and community at large (to the RMONMIB WG mailing list
  311.    at 'rmonmib@cisco.com') will be collected and added to this document.
  312.  
  313.    Macros submissions will be collected in the IANA's MIB files under
  314.    the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in
  315.    the RMONMIB working group mailing list message archive file
  316.    "ftp://ftp.cisco.com/ftp/rmonmib/rmonmib".
  317.  
  318.    This document does not discuss auto-discovery and auto-population of
  319.    the protocolDirTable. This functionality is not explicitly defined by
  320.    the RMON standard. An agent should populate the directory with
  321.    'interesting' protocols--depending on the intended applications.
  322.  
  323. 3.3.  Relationship to the Other MIBs
  324.  
  325.    The RMON Protocol Identifiers document is intended for use with the
  326.    protocolDirTable within the RMON MIB. It is not relevant to any other
  327.    MIB, or intended for use with any other MIB.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Bierman & Iddon             Standards Track                     [Page 6]
  339.  
  340. RFC 2074               RMON Protocol Identifiers            January 1997
  341.  
  342.  
  343. 4.  Protocol Identifier Encoding
  344.  
  345.    The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID
  346.    and protocolDirParameters. To encode the table index, each variable-
  347.    length string is converted to an OBJECT IDENTIFIER fragment,
  348.    according to the encoding rules in section 7.7 of RFC 1902 [RFC1902].
  349.    Then the index fragments are simply concatenated. (Refer to figures
  350.    1a - 1d below for more detail.)
  351.  
  352.    The first OCTET STRING (protocolDirID) is composed of one or more 4-
  353.    octet "layer-identifiers". The entire string uniquely identifies a
  354.    particular protocol encapsulation tree. The second OCTET STRING,
  355.    (protocolDirParameters) which contains a corresponding number of 1-
  356.    octet protocol-specific parameters, one for each 4-octet layer-
  357.    identifier in the first string.
  358.  
  359.    A protocol layer is normally identified by a single 32-bit value.
  360.    Each layer-identifier is encoded in the ProtocolDirID OCTET STRING
  361.    INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent
  362.    each byte of the 32-bit value in network byte order.  If a particular
  363.    protocol layer cannot be encoded into 32 bits, (except for the
  364.    'vsnap' base layer) then it must be defined as a 'ianaAssigned'
  365.    protocol (see below for details on IANA assigned protocols).
  366.  
  367.    The following figures show the differences between the OBJECT
  368.    IDENTIFIER and OCTET STRING encoding of the protocol identifier
  369.    string.
  370.  
  371.  
  372.                    Fig. 1a
  373.          protocolDirTable INDEX Format
  374.          -----------------------------
  375.  
  376.      +---+--------------------------+---+---------------+
  377.      | c !                          | c !  protocolDir  |
  378.      | n !  protocolDirID           | n !  Parameters   |
  379.      | t !                          | t !               |
  380.      +---+--------------------------+---+---------------+
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Bierman & Iddon             Standards Track                     [Page 7]
  395.  
  396. RFC 2074               RMON Protocol Identifiers            January 1997
  397.  
  398.  
  399.                    Fig. 1b
  400.          protocolDirTable OCTET STRING Format
  401.          ------------------------------------
  402.  
  403.       protocolDirID
  404.      +----------------------------------------+
  405.      |                                        |
  406.      |              4 * N octets              |
  407.      |                                        |
  408.      +----------------------------------------+
  409.  
  410.      protocolDirParameters
  411.      +----------+
  412.      |          |
  413.      | N octets |
  414.      |          |
  415.      +----------+
  416.  
  417.                     Fig. 1c
  418.         protocolDirTable INDEX Format Example
  419.         -------------------------------------
  420.  
  421.      protocolDirID                   protocolDirParameters
  422.      +---+--------+--------+--------+--------+---+---+---+---+---+
  423.      | c |  proto |  proto |  proto |  proto | c |par|par|par|par|
  424.      | n |  base  |    L3  |   L4   |   L5   | n |ba-| L3| L4| L5|
  425.      | t |(+flags)|        |        |        | t |se |   |   |   |
  426.      +---+--------+--------+--------+--------+---+---+---+---+---+ subOID
  427.      | 1 | 4 or 8 |    4   |    4   |    4   | 1 |1/2| 1 | 1 | 1 | count
  428.  
  429.      where N is the number of protocol-layer-identifiers required
  430.      for the entire encapsulation of the named protocol. Note that
  431.      the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
  432.      All other protocol layers are either encoded into 4 sub-identifiers
  433.      or encoded as a 'ianaAssigned' protocol.
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Bierman & Iddon             Standards Track                     [Page 8]
  451.  
  452. RFC 2074               RMON Protocol Identifiers            January 1997
  453.  
  454.  
  455.                     Fig. 1d
  456.        protocolDirTable OCTET STRING Format Example
  457.        --------------------------------------------
  458.  
  459.      protocolDirID
  460.      +--------+--------+--------+--------+
  461.      |  proto |  proto |  proto |  proto |
  462.      |   base |    L3  |   L4   |   L5   |
  463.      |        |        |        |        |
  464.      +--------+--------+--------+--------+ octet
  465.      | 4 or 8 |    4   |    4   |    4   | count
  466.  
  467.  
  468.      protocolDirParameters
  469.      +---+---+---+---+
  470.      |par|par|par|par|
  471.      |ba-| L3| L4| L5|
  472.      |se |   |   |   |
  473.      +---+---+---+---+ octet
  474.      |1/2| 1 | 1 | 1 | count
  475.  
  476.      where N is the number of protocol-layer-identifiers required
  477.      for the entire encapsulation of the named protocol. Note that
  478.      the 'vsnap' base layer identifier is encoded into 8
  479.      protocolDirID sub-identifiers and 2 protocolDirParameters
  480.      sub-identifiers.
  481.  
  482.    Although this example indicates four encapsulated protocols, in
  483.    practice, any non-zero number of layer-identifiers may be present,
  484.    theoretically limited only by OBJECT IDENTIFIER length restrictions,
  485.    as specified in section 3.5 of RFC 1902 [RFC1902].
  486.  
  487.    Note that these two strings would not be concatenated together if
  488.    ever returned in a GetResponse PDU, since they are different MIB
  489.    objects.  However, protocolDirID and protocolDirParameters are not
  490.    currently readable MIB objects.
  491.  
  492. 4.1.  ProtocolDirTable INDEX Format Examples
  493.  
  494.     -- HTTP; fragments counted from IP and above
  495.     ether2.ip.tcp.www-http =
  496.        16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
  497.  
  498.     -- SNMP over UDP/IP over SNAP
  499.     snap.ip.udp.snmp =
  500.        16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Bierman & Iddon             Standards Track                     [Page 9]
  507.  
  508. RFC 2074               RMON Protocol Identifiers            January 1997
  509.  
  510.  
  511.     -- SNMP over IPX over SNAP
  512.     snap.ipx.snmp =
  513.        12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
  514.  
  515.     -- SNMP over IPX over raw8023
  516.     -- ianaAssigned(ipxOverRaw8023(1)).snmp =
  517.        12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
  518.  
  519.     -- IPX over LLC
  520.     llc.ipx =
  521.        8.0.0.0.2.0.224.224.3.2.0.0
  522.  
  523.     -- SNMP over UDP/IP over any link layer
  524.     -- wildcard-ether2.ip.udp.snmp
  525.        16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
  526.  
  527.     -- IP over any link layer; base encoding is IP over ether2
  528.     -- wildcard-ether2.ip
  529.        8.1.0.0.1.0.0.8.0.2.0.0
  530.  
  531.    -- AppleTalk Phase 2 over ether2
  532.    -- ether2.atalk
  533.       8.0.0.0.1.0.0.128.155.2.0.0
  534.  
  535.    -- AppleTalk Phase 2 over vsnap
  536.    -- vsnap(apple).atalk
  537.       12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
  538.  
  539. 4.2.  Protocol Identifier Macro Format
  540.  
  541.    The following example is meant to introduce the protocol-identifier
  542.    macro. (The syntax is not quite ASN.1.) This macro is used to
  543.    represent both protocols and protocol-variants.
  544.  
  545.    If the 'VariantOfPart' component of the macro is present, then the
  546.    macro represents a protocol-variant instead of a protocol.  A
  547.    protocol- variant-identifier is used only for IANA assigned
  548.    protocols, enumerated under the 'ianaAssigned' base-layer.
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Bierman & Iddon             Standards Track                    [Page 10]
  563.  
  564. RFC 2074               RMON Protocol Identifiers            January 1997
  565.  
  566.  
  567.      RMON-PROTOCOL-IDENTIFIER MACRO ::=
  568.      BEGIN
  569.              PIMacroName "PROTOCOL-IDENTIFIER"
  570.                      VariantOfPart
  571.                      "PARAMETERS"   ParamPart
  572.                      "ATTRIBUTES"   AttrPart
  573.                      "DESCRIPTION"  Text
  574.                      ChildDescrPart
  575.                      AddrDescrPart
  576.                      DecodeDescrPart
  577.                      ReferPart
  578.              "::=" "{" EncapsPart "}"
  579.  
  580.              PIMacroName ::=
  581.                  identifier
  582.  
  583.              VariantOfPart ::=
  584.                  "VARIANT-OF" identifier | empty
  585.  
  586.              ParamPart ::=
  587.                  "{" ParamList "}"
  588.  
  589.              ParamList ::=
  590.                  Params | empty
  591.  
  592.              Params ::=
  593.                  Param | Params "," Param
  594.  
  595.              Param ::=
  596.                  identifier "(" nonNegativeNumber ")"
  597.  
  598.              AttrPart ::=
  599.                  "{" AttrList "}"
  600.  
  601.              AttrList ::=
  602.                  Attrs | empty
  603.  
  604.              Attrs ::=
  605.                  Attr | Attrs "," Attr
  606.  
  607.              Attr ::=
  608.                  identifier "(" nonNegativeNumber ")"
  609.  
  610.              ChildDescrPart ::=
  611.                  "CHILDREN" Text | empty
  612.  
  613.              AddrDescrPart ::=
  614.                  "ADDRESS-FORMAT" Text | empty
  615.  
  616.  
  617.  
  618. Bierman & Iddon             Standards Track                    [Page 11]
  619.  
  620. RFC 2074               RMON Protocol Identifiers            January 1997
  621.  
  622.  
  623.              DecodeDescrPart ::=
  624.                  "DECODING" Text | empty
  625.  
  626.              ReferPart ::=
  627.                  "REFERENCE" Text | empty
  628.  
  629.              EncapsPart ::=
  630.                  "{" Encaps "}"
  631.  
  632.              Encaps ::=
  633.                  Encap | Encaps "," Encap
  634.  
  635.              Encap ::=
  636.                  BaseEncap | NormalEncap | VsnapEncap | IanaEncap
  637.  
  638.              BaseEncap ::=
  639.                  nonNegativeNumber
  640.  
  641.              NormalEncap ::=
  642.                  identifier nonNegativeNumber
  643.  
  644.              VsnapEncap ::=
  645.                  identifier "(" nonNegativeNumber ")" nonNegativeNumber
  646.  
  647.              IanaEncap ::=
  648.                  "ianaAssigned" nonNegativeNumber
  649.                  | "ianaAssigned" identifier
  650.                  | "ianaAssigned" identifier "(" nonNegativeNumber ")"
  651.  
  652.              Text ::=
  653.                  """" string """"
  654.      END
  655.  
  656. 4.2.1.  Mapping of the Protocol Name
  657.  
  658.    The 'PIMacroName' value should be a lower-case ASCII string, and
  659.    contain the name or acronym identifying the protocol.  NMS
  660.    applications may treat protocol names as case-insensitive strings,
  661.    and agent implementations must make sure the protocolDirTable does
  662.    not contain any instances of the protocolDirDescr object which differ
  663.    only in the case of one of more letters (if the identifiers are
  664.    intended to represent different protocols).
  665.  
  666.    It is possible that different encapsulations of the same protocol
  667.    (which are represented by different entries in the protocolDirTable)
  668.    will be assigned the same protocol name.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Bierman & Iddon             Standards Track                    [Page 12]
  675.  
  676. RFC 2074               RMON Protocol Identifiers            January 1997
  677.  
  678.  
  679.    A protocol name should match the "most well-known" name or acronym
  680.    for the indicated protocol.  For example, the document indicated by
  681.    the URL:
  682.  
  683.        ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
  684.  
  685.    defines IP Protocol field values, so protocol-identifier macros for
  686.    children of IP should be given names consistent with the protocol
  687.    names found in this authoritative document.
  688.  
  689. 4.2.2.  Mapping of the VARIANT-OF Clause
  690.  
  691.    This clause is present for IANA assigned protocols only.  It
  692.    identifies the protocol-identifier macro that most closely represents
  693.    this particular protocol, and is known as the "reference protocol".
  694.    (A protocol-identifier macro must exist for the reference protocol.)
  695.    When this clause is present in a protocol-identifier macro, the macro
  696.    is called a 'protocol-variant-identifier'.
  697.  
  698.    Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-
  699.    identifier macro should not be duplicated in the protocol-variant-
  700.    identifier macro, if the 'variant' protocols' semantics are identical
  701.    for a given clause.
  702.  
  703.    Since the PARAMETERS and ATTRIBUTES clauses must be present in a
  704.    protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
  705.    "PARAMETERS {}") must be present in a protocol-variant-identifier
  706.    macro, and the 'ParamPart' and 'AttrPart' found in the reference
  707.    protocol- identifier macro examined instead.
  708.  
  709.    Note that if a 'ianaAssigned' protocol is defined that is not a
  710.    variant of any other documented protocol, then the protocol-
  711.    identifier macro should be used instead of the protocol-variant-
  712.    identifier version of the macro.
  713.  
  714. 4.2.3.  Mapping of the PARAMETERS Clause
  715.  
  716.    The protocolDirParameters object provides an NMS the ability to turn
  717.    on and off expensive probe resources. An agent may support a given
  718.    parameter all the time, not at all, or subject to current resource
  719.    load.
  720.  
  721.    The PARAMETERS clause is a list of bit definitions which can be
  722.    directly encoded into the associated ProtocolDirParameters octet in
  723.    network byte order. Zero or more bit definitions may be present. Only
  724.    bits 0-7 are valid encoding values. This clause defines the entire
  725.    BIT set allowed for a given protocol. A conforming agent may choose
  726.    to implement a subset of zero or more of these PARAMETERS.
  727.  
  728.  
  729.  
  730. Bierman & Iddon             Standards Track                    [Page 13]
  731.  
  732. RFC 2074               RMON Protocol Identifiers            January 1997
  733.  
  734.  
  735.    By convention, the following common bit definitions are used by
  736.    different protocols.  These bit positions must not be used for other
  737.    parameters. They should be reserved if not used by a given protocol.
  738.    Bits are encoded in network-byte order.
  739.  
  740.          Table 3.1  Reserved PARAMETERS Bits
  741.          ------------------------------------
  742.  
  743. Bit Name              Description
  744. ---------------------------------------------------------------------
  745. 0   countsFragments   higher-layer protocols encapsulated within
  746.                       this protocol will be counted correctly even
  747.                       if this protocol fragments the upper layers
  748.                       into multiple packets.
  749. 1   tracksSessions    correctly attributes all packets of a protocol
  750.                       which starts sessions on well known ports or
  751.                       sockets and then transfers them to dynamically
  752.                       assigned ports or sockets thereafter (e.g. TFTP).
  753.  
  754.    The PARAMETERS clause must be present in all protocol-identifier
  755.    macro declarations, but may be equal to zero (empty). Note that an
  756.    NMS must determine if a given PARAMETER bit is supported by
  757.    attempting to create the desired protocolDirEntry The associated
  758.    ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not
  759.    exist.
  760.  
  761. 4.2.3.1.  Mapping of the 'countsFragments(0)' BIT
  762.  
  763.    This bit indicates whether the probe is correctly attributing all
  764.    fragmented packets of the specified protocol, even if individual
  765.    frames carrying this protocol cannot be identified as such.  Note
  766.    that the probe is not required to actually present any re-assembled
  767.    datagrams (for address-analysis, filtering, or any other purpose) to
  768.    the NMS.
  769.  
  770.    This bit may only be set in a protocolDirParameters octet which
  771.    corresponds to a protocol that supports fragmentation and reassembly
  772.    in some form. Note that TCP packets are not considered 'fragmented-
  773.    streams' and so TCP is not eligible.
  774.  
  775.    This bit may be set in at most one protocolDirParameters octet within
  776.    a protocolDirTable INDEX.
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Bierman & Iddon             Standards Track                    [Page 14]
  787.  
  788. RFC 2074               RMON Protocol Identifiers            January 1997
  789.  
  790.  
  791. 4.2.3.2.  Mapping of the 'tracksSessions(1)' BIT
  792.  
  793.    The 'tracksSessions(1)' bit indicates whether frames which are part
  794.    of remapped-sessions (e.g. TFTP download sessions) are correctly
  795.    counted by the probe. For such a protocol, the probe must usually
  796.    analyze all packets received on the indicated interface, and maintain
  797.    some state information, (e.g. the remapped UDP port number for TFTP).
  798.  
  799.    The semantics of the 'tracksSessions' parameter are independent of
  800.    the other protocolDirParameters definitions, so this parameter may be
  801.    combined with any other legal parameter configurations.
  802.  
  803. 4.2.4.  Mapping of the ATTRIBUTES Clause
  804.  
  805.    The protocolDirType object provides an NMS with an indication of a
  806.    probe's capabilities for decoding a given protocol, or the general
  807.    attributes of the particular protocol.
  808.  
  809.    The ATTRIBUTES clause is a list of bit definitions which are encoded
  810.    into the associated instance of ProtocolDirType. The BIT definitions
  811.    are specified in the SYNTAX clause of the protocolDirType MIB object.
  812.  
  813.          Table 3.2  Reserved ATTRIBUTES Bits
  814.          ------------------------------------
  815.  
  816.      Bit Name              Description
  817.      ---------------------------------------------------------------------
  818.      0  hasChildren        indicates that there may be children of
  819.                            this protocol defined in the protocolDirTable
  820.                            (by either the agent or the manager).
  821.      1  addressRecognitionCapable
  822.                            indicates that this protocol can be used
  823.                            to generate host and matrix table entries.
  824.  
  825.    The ATTRIBUTES clause must be present in all protocol-identifier
  826.    macro declarations, but may be empty.
  827.  
  828. 4.2.5.  Mapping of the DESCRIPTION Clause
  829.  
  830.    The DESCRIPTION clause provides a textual description of the protocol
  831.    identified by this macro.  Notice that it should not contain details
  832.    about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
  833.    REFERENCE clauses.
  834.  
  835.    The DESCRIPTION clause must be present in all protocol-identifier
  836.    macro declarations.
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Bierman & Iddon             Standards Track                    [Page 15]
  843.  
  844. RFC 2074               RMON Protocol Identifiers            January 1997
  845.  
  846.  
  847. 4.2.6.  Mapping of the CHILDREN Clause
  848.  
  849.    The CHILDREN clause provides a description of child protocols for
  850.    protocols which support them. It has three sub-sections:
  851.  
  852.   -  Details on the field(s)/value(s) used to select the child protocol,
  853.      and how that selection process is performed
  854.  
  855.   -  Details on how the value(s) are encoded in the protocol identifier
  856.      octet string
  857.  
  858.   -  Details on how child protocols are named with respect to their
  859.      parent protocol label(s)
  860.  
  861.    The CHILDREN clause must be present in all protocol-identifier macro
  862.    declarations in which the 'hasChildren(0)' BIT is set in the
  863.    ATTRIBUTES clause.
  864.  
  865. 4.2.7.  Mapping of the ADDRESS-FORMAT Clause
  866.  
  867.    The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
  868.    format(s) used when encoding addresses.
  869.  
  870.    This clause must be present in all protocol-identifier macro
  871.    declarations in which the 'addressRecognitionCapable(1)' BIT is set
  872.    in the ATTRIBUTES clause.
  873.  
  874. 4.2.8.  Mapping of the DECODING Clause
  875.  
  876.    The DECODING clause provides a description of the decoding procedure
  877.    for the specified protocol. It contains useful decoding hints for the
  878.    implementor, but should not over-replicate information in documents
  879.    cited in the REFERENCE clause.  It might contain a complete
  880.    description of any decoding information required.
  881.  
  882.    For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
  883.    offset and type information for the field(s) used for child selection
  884.    as well as information on determining the start of the child
  885.    protocol.
  886.  
  887.    For 'addressRecognitionCapable' protocols this includes offset and
  888.    type information for the field(s) used to generate addresses.
  889.  
  890.    The DECODING clause is optional, and may be omitted if the REFERENCE
  891.    clause contains pointers to decoding information for the specified
  892.    protocol.
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Bierman & Iddon             Standards Track                    [Page 16]
  899.  
  900. RFC 2074               RMON Protocol Identifiers            January 1997
  901.  
  902.  
  903. 4.2.9.  Mapping of the REFERENCE Clause
  904.  
  905.    If a publicly available reference document exists for this protocol
  906.    it should be listed here.  Typically this will be a URL if possible;
  907.    if not then it will be the name and address of the controlling body.
  908.  
  909.    The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
  910.    amount of information which may currently be obtained from an
  911.    'authoritative' document, such as the Assigned Numbers document
  912.    [RFC1700]. Any duplication or paraphrasing of information should be
  913.    brief and consistent with the authoritative document.
  914.  
  915.    The REFERENCE clause is optional, but should be implemented if an
  916.    authoritative reference exists for the protocol (especially for
  917.    standard protocols).
  918.  
  919. 4.2.10.  Evaluating a Protocol-Identifier INDEX
  920.  
  921.    The following evaluation is done after protocolDirTable INDEX value
  922.    has been converted into two OCTET STRINGs according to the INDEX
  923.    encoding rules specified in the SMI [RFC1902].
  924.  
  925.    Protocol-identifiers are evaluated left to right, starting with the
  926.    protocolDirID, which length should be evenly divisible by four. The
  927.    protocolDirParameters length should be exactly one quarter of the
  928.    protocolDirID string length.
  929.  
  930.    Protocol-identifier parsing starts with the base layer identifier,
  931.    which must be present, and continues for one or more upper layer
  932.    identifiers, until all OCTETs of the protocolDirID have been used.
  933.    Layers may not be skipped, so identifiers such as 'SNMP over IP' or
  934.    'TCP over anylink' can not exist.
  935.  
  936.    The base-layer-identifier also contains a 'special function
  937.    identifier' which may apply to the rest of the protocol identifier.
  938.  
  939.    Wild-carding at the base layer within a protocol encapsulation is the
  940.    only supported special function at this time. Refer to the 'Base
  941.    Protocol Identifiers' section for wildcard encoding rules.
  942.  
  943.    After the protocol-tree identified in protocolDirID has been parsed,
  944.    each parameter bit-mask (one octet for each 4-octet layer-identifier)
  945.    is evaluated, and applied to the corresponding protocol layer.
  946.  
  947.    A protocol-identifier label may map to more than one value.  For
  948.    instance, 'ip' maps to 5 distinct values, one for each supported
  949.    encapsulation.  (see the 'IP' section under 'L3 Protocol
  950.    Identifiers'),
  951.  
  952.  
  953.  
  954. Bierman & Iddon             Standards Track                    [Page 17]
  955.  
  956. RFC 2074               RMON Protocol Identifiers            January 1997
  957.  
  958.  
  959.    It is important to note that these macros are conceptually expanded
  960.    at implementation time, not at run time.
  961.  
  962.    If all the macros are expanded completely by substituting all
  963.    possible values of each label for each child protocol, a list of all
  964.    possible protocol-identifiers is produced.  So 'ip' would result in 5
  965.    distinct protocol-identifiers.  Likewise each child of 'ip' would map
  966.    to at least 5 protocol-identifiers, one for each encapsulation (e.g.
  967.    ip over ether2, ip over LLC, etc.).
  968.  
  969. 5.  Protocol Identifier Macros
  970.  
  971.    The following PROTOCOL IDENTIFIER macros can be used to construct
  972.    protocolDirID and protocolDirParameters strings.
  973.  
  974.    The sections defining protocol examples are intended to grow over
  975.    subsequent releases. Minimal protocol support is included at this
  976.    time.  (Refer to section 3.2 for details on the protocol macro update
  977.    procedure.)
  978.  
  979.    An identifier is encoded by constructing the base-identifier, then
  980.    adding one layer-identifier for each encapsulated protocol.
  981.  
  982. 5.1.  Base Identifier Encoding
  983.  
  984.    The first layer encapsulation is called the base identifier and it
  985.    contains optional protocol-function information and the base layer
  986.    (e.g.  MAC layer) enumeration value used in this protocol identifier.
  987.  
  988.    The base identifier is encoded as four octets as shown in figure 2.
  989.  
  990.           Fig. 2
  991.      base-identifier format
  992.      +---+---+---+---+
  993.      |   |   |   |   |
  994.      | f |op1|op2| m |
  995.      |   |   |   |   |
  996.      +---+---+---+---+ octet
  997.      | 1 | 1 | 1 | 1 | count
  998.  
  999.    The first octet ('f') is the special function code, found in table
  1000.    4.1.  The next two octets ('op1' and 'op2') are operands for the
  1001.    indicated function. If not used, an operand must be set to zero.  The
  1002.    last octet, 'm', is the enumerated value for a particular base layer
  1003.    encapsulation, found in table 4.2.  All four octets are encoded in
  1004.    network-byte-order.
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Bierman & Iddon             Standards Track                    [Page 18]
  1011.  
  1012. RFC 2074               RMON Protocol Identifiers            January 1997
  1013.  
  1014.  
  1015. 5.1.1.  Protocol Identifier Functions
  1016.  
  1017.    The base layer identifier contains information about any special
  1018.    functions to perform during collections of this protocol, as well as
  1019.    the base layer encapsulation identifier.
  1020.  
  1021.    The first three octets of the identifier contain the function code
  1022.    and two optional operands. The fourth octet contains the particular
  1023.    base layer encapsulation used in this protocol (fig. 2).
  1024.  
  1025.      Table 4.1  Assigned Protocol Identifier Functions
  1026.      -------------------------------------------------
  1027.  
  1028.            Function     ID    Param1               Param2
  1029.            ----------------------------------------------------
  1030.            none          0    not used (0)         not used (0)
  1031.            wildcard      1    not used (0)         not used (0)
  1032.  
  1033. 5.1.1.1.  Function 0: No-op
  1034.  
  1035.    If the function ID field (1st octet) is equal to zero, the the 'op1'
  1036.    and 'op2' fields (2nd and 3rd octets) must also be equal to zero.
  1037.    This special value indicates that no functions are applied to the
  1038.    protocol identifier encoded in the remaining octets. The identifier
  1039.    represents a normal protocol encapsulation.
  1040.  
  1041. 5.1.1.2.  Function 1: Protocol Wildcard Function
  1042.  
  1043.    The wildcard function (function-ID = 1), is used to aggregate
  1044.    counters, by using a single protocol value to indicate potentially
  1045.    many base layer encapsulations of a particular network layer
  1046.    protocol. A protocolDirEntry of this type will match any base-layer
  1047.    encapsulation of the same protocol.
  1048.  
  1049.    The 'op1' field (2nd octet) is not used and must be set to zero.
  1050.  
  1051.    The 'op2' field (3rd octet) is not used and must be set to zero.
  1052.  
  1053.    Each wildcard protocol identifier must be defined in terms of a 'base
  1054.    encapsulation'. This should be as 'standard' as possible for
  1055.    interoperability purposes. If an encapsulation over 'ether2' is
  1056.    permitted, than this should be used as the base encapsulation.
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Bierman & Iddon             Standards Track                    [Page 19]
  1067.  
  1068. RFC 2074               RMON Protocol Identifiers            January 1997
  1069.  
  1070.  
  1071.    The agent may also be requested to count some or all of the
  1072.    individual encapsulations for the same protocols, in addition to
  1073.    wildcard counting.  Note that the RMON-2 MIB [RMON2] does not require
  1074.    that agents maintain counters for multiple encapsulations of the same
  1075.    protocol.  It is an implementation-specific matter as to how an agent
  1076.    determines which protocol combinations to allow in the
  1077.    protocolDirTable at any given time.
  1078.  
  1079. 5.2.  Base Layer Protocol Identifiers
  1080.  
  1081.    The base layer is mandatory, and defines the base encapsulation of
  1082.    the packet and any special functions for this identifier.
  1083.  
  1084.    There are no suggested protocolDirParameters bits for the base layer.
  1085.  
  1086.    The suggested ProtocolDirDescr field for the base layer is given by
  1087.    the corresponding "Name" field in the table 4.1 below. However,
  1088.    implementations are only required to use the appropriate integer
  1089.    identifier values.
  1090.  
  1091.    For most base layer protocols, the protocolDirType field should
  1092.    contain bits set for  the 'hasChildren(0)' and
  1093.    'addressRecognitionCapable(1)' attributes.  However, the special
  1094.    'ianaAssigned' base layer should have no parameter or attribute bits
  1095.    set.
  1096.  
  1097.    By design, only 255 different base layer encapsulations are
  1098.    supported.  There are five base encapsulation values defined at this
  1099.    time. New base encapsulations (e.g. for new media types) are expected
  1100.    to be added over time.
  1101.  
  1102.      Table 4.2  Base Layer Encoding Values
  1103.      --------------------------------------
  1104.  
  1105.            Name          ID
  1106.            ------------------
  1107.            ether2        1
  1108.            llc           2
  1109.            snap          3
  1110.            vsnap         4
  1111.            ianaAssigned    5
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Bierman & Iddon             Standards Track                    [Page 20]
  1123.  
  1124. RFC 2074               RMON Protocol Identifiers            January 1997
  1125.  
  1126.  
  1127. 5.2.1.  Ether2 Encapsulation
  1128.  
  1129. ether2 PROTOCOL-IDENTIFIER
  1130.     PARAMETERS { }
  1131.     ATTRIBUTES {
  1132.         hasChildren(0),
  1133.         addressRecognitionCapable(1)
  1134.     }
  1135.     DESCRIPTION
  1136.        "DIX Ethernet, also called Ethernet-II."
  1137.     CHILDREN
  1138.        "The Ethernet-II type field is used to select child protocols.
  1139.        This is a 16-bit field.  Child protocols are deemed to start at
  1140.        the first octet after this type field.
  1141.  
  1142.        Children of this protocol are encoded as [ 0.0.0.1 ], the
  1143.        protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
  1144.        'a' and 'b' are the network byte order encodings of the MSB and
  1145.        LSB of the Ethernet-II type value.
  1146.  
  1147.        For example, a protocolDirID-fragment value of:
  1148.           0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
  1149.  
  1150.        Children of are named as 'ether2' followed by the type field
  1151.        value in hexadecimal.  The above example would be declared as:
  1152.           ether2 0x0800"
  1153.     ADDRESS-FORMAT
  1154.        "Ethernet addresses are 6 octets in network order."
  1155.     DECODING
  1156.        "Only type values greater than or equal to 1500 decimal indicate
  1157.        Ethernet-II frames; lower values indicate 802.3 encapsulation
  1158.        (see below)."
  1159.     REFERENCE
  1160.        "A Standard for the Transmission of IP Datagrams over Ethernet
  1161.        Networks; RFC 894 [RFC894].
  1162.  
  1163.        The authoritative list of Ether Type values is identified by the
  1164.        URL:
  1165.  
  1166.           ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
  1167.     ::= { 1 }
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Bierman & Iddon             Standards Track                    [Page 21]
  1179.  
  1180. RFC 2074               RMON Protocol Identifiers            January 1997
  1181.  
  1182.  
  1183. 5.2.2.  LLC Encapsulation
  1184.  
  1185. llc PROTOCOL-IDENTIFIER
  1186.     PARAMETERS { }
  1187.     ATTRIBUTES {
  1188.         hasChildren(0),
  1189.         addressRecognitionCapable(1)
  1190.     }
  1191.     DESCRIPTION
  1192.        "The LLC (802.2) protocol."
  1193.     CHILDREN
  1194.        "The LLC SSAP and DSAP (Source/Dest Service Access Points) are
  1195.        used to select child protocols.  Each of these is one octet long,
  1196.        although the least significant bit is a control bit and should be
  1197.        masked out in most situations.  Typically SSAP and DSAP (once
  1198.        masked) are the same for a given protocol - each end implicitly
  1199.        knows whether it is the server or client in a client/server
  1200.        protocol.  This is only a convention, however, and it is possible
  1201.        for them to be different.  The SSAP is matched against child
  1202.        protocols first.  If none is found then the DSAP is matched
  1203.        instead.  The child protocol is deemed to start at the first
  1204.        octet after the LLC control field(s).
  1205.  
  1206.        Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
  1207.        identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
  1208.        the SAP value which maps to the child protocol.  For example, a
  1209.        protocolDirID-fragment value of:
  1210.           0.0.0.2.0.0.0.240
  1211.  
  1212.        defines NetBios over LLC.
  1213.  
  1214.        Children are named as 'llc' followed by the SAP value in
  1215.        hexadecimal.  So the above example would have been named:
  1216.           llc 0xf0"
  1217.     ADDRESS-FORMAT
  1218.        "The address consists of 6 octets of MAC address in network
  1219.        order.  Source routing bits should be stripped out of the address
  1220.        if present."
  1221.     DECODING
  1222.        "Notice that LLC has a variable length protocol header; there are
  1223.        always three octets (DSAP, SSAP, control).  Depending on the
  1224.        value of the control bits in the DSAP, SSAP and control fields
  1225.        there may be an additional octet of control information.
  1226.  
  1227.        LLC can be present on several different media.  For 802.3 and
  1228.        802.5 its presence is mandated (but see ether2 and raw802.3
  1229.        encapsulations).  For 802.5 there is no other link layer
  1230.        protocol.
  1231.  
  1232.  
  1233.  
  1234. Bierman & Iddon             Standards Track                    [Page 22]
  1235.  
  1236. RFC 2074               RMON Protocol Identifiers            January 1997
  1237.  
  1238.  
  1239.        Notice also that the raw802.3 link layer protocol may take
  1240.        precedence over this one in a protocol specific manner such that
  1241.        it may not be possible to utilize all LSAP values if raw802.3 is
  1242.        also present."
  1243.     REFERENCE
  1244.        "The authoritative list of LLC LSAP values is controlled by the
  1245.        IEEE Registration Authority:
  1246.        IEEE Registration Authority
  1247.           c/o Iris Ringel
  1248.           IEEE Standards Dept
  1249.           445 Hoes Lane, P.O. Box 1331
  1250.           Piscataway, NJ 08855-1331
  1251.           Phone +1 908 562 3813
  1252.           Fax: +1 908 562 1571"
  1253.     ::= { 2 }
  1254.  
  1255. 5.2.3.  SNAP over LLC (OUI=000) Encapsulation
  1256.  
  1257. snap PROTOCOL-IDENTIFIER
  1258.     PARAMETERS { }
  1259.     ATTRIBUTES {
  1260.         hasChildren(0),
  1261.         addressRecognitionCapable(1)
  1262.     }
  1263.     DESCRIPTION
  1264.        "The Sub-Network Access Protocol (SNAP) is layered on top of LLC
  1265.        protocol, allowing Ethernet-II protocols to be run over a media
  1266.        restricted to LLC."
  1267.     CHILDREN
  1268.        "Children of 'snap' are identified by Ethernet-II type values;
  1269.        the SNAP PID (Protocol Identifier) field is used to select the
  1270.        appropriate child.  The entire SNAP protocol header is consumed;
  1271.        the child protocol is assumed to start at the next octet after
  1272.        the PID.
  1273.  
  1274.        Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
  1275.        identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
  1276.        are the MSB and LSB of the Ethernet-II type value.  For example,
  1277.        a protocolDirID-fragment value of:
  1278.           0.0.0.3.0.0.8.0
  1279.  
  1280.        defines the IP/SNAP protocol.
  1281.  
  1282.        Children of this protocol are named 'snap' followed by the
  1283.        Ethernet-II type value in hexadecimal.  The above example would
  1284.        be named:
  1285.  
  1286.           snap 0x0800"
  1287.  
  1288.  
  1289.  
  1290. Bierman & Iddon             Standards Track                    [Page 23]
  1291.  
  1292. RFC 2074               RMON Protocol Identifiers            January 1997
  1293.  
  1294.  
  1295.     ADDRESS-FORMAT
  1296.          "The address format for SNAP is the same as that for LLC"
  1297.     DECODING
  1298.        "SNAP is only present over LLC.  Both SSAP and DSAP will be 0xAA
  1299.        and a single control octet will be present.  There are then three
  1300.        octets of OUI and two octets of PID.  For this encapsulation the
  1301.        OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
  1302.     REFERENCE
  1303.        "SNAP Identifier values are assigned by the IEEE Standards
  1304.        Office.  The address is:
  1305.                IEEE Registration Authority
  1306.                c/o Iris Ringel
  1307.                IEEE Standards Dept
  1308.                445 Hoes Lane, P.O. Box 1331
  1309.                Piscataway, NJ 08855-1331
  1310.                Phone +1 908 562 3813
  1311.                Fax: +1 908 562 1571"
  1312.     ::= { 3 }
  1313.  
  1314. 5.2.4.  SNAP over LLC (OUI != 000) Encapsulation
  1315.  
  1316. vsnap PROTOCOL-IDENTIFIER
  1317.     PARAMETERS { }
  1318.     ATTRIBUTES {
  1319.         hasChildren(0),
  1320.         addressRecognitionCapable(1)
  1321.     }
  1322.     DESCRIPTION
  1323.        "This pseudo-protocol handles all SNAP packets which do not have
  1324.        a zero OUI.  See 'snap' above for details of those that do."
  1325.     CHILDREN
  1326.        "Children of 'vsnap' are selected by the 3 octet OUI; the PID is
  1327.        not parsed; child protocols are deemed to start with the first
  1328.        octet of the SNAP PID field, and continue to the end of the
  1329.        packet.
  1330.  
  1331.        Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
  1332.        identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
  1333.        'a', 'b' and 'c' are the 3 octets of the OUI field in network
  1334.        byte order. This is in turn followed by the 16-bit EtherType
  1335.        value, where the 'd' and 'e' represent the MSB and LSB of the
  1336.        EtherType, respectively.
  1337.  
  1338.        For example, a protocolDirID-fragment value of:
  1339.          0.0.0.4.0.8.0.7.0.0.128.155
  1340.        defines the AppleTalk Phase 2 protocol over vsnap.
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Bierman & Iddon             Standards Track                    [Page 24]
  1347.  
  1348. RFC 2074               RMON Protocol Identifiers            January 1997
  1349.  
  1350.  
  1351.        Note that two protocolDirParameters octets must be present in
  1352.        protocolDirTable INDEX values for 'vsnap' protocols.  The first
  1353.        protocolDirParameters octet defines the actual parameters. The
  1354.        second protocolDirParameters octet is not used and must be set to
  1355.        zero.
  1356.  
  1357.        Children are named as 'vsnap(<OUI>) <ethertype>', where the
  1358.        '<OUI>' field is represented as 3 octets in hexadecimal notation
  1359.        or the ASCII string associated with the OUI value. The
  1360.        <ethertype> field is represented by the 2 byte EtherType value in
  1361.        hexadecimal notation. So the above example would be named:
  1362.  
  1363.          'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
  1364.     ADDRESS-FORMAT
  1365.        "The LLC address format is inherited by 'vsnap'.  See the 'llc'
  1366.        protocol identifier for more details."
  1367.     DECODING
  1368.        "Same as for 'snap' except the OUI is non-zero."
  1369.     REFERENCE
  1370.        "SNAP Identifier values are assigned by the IEEE Standards
  1371.        Office.  The address is:
  1372.                IEEE Registration Authority
  1373.                c/o Iris Ringel
  1374.                IEEE Standards Dept
  1375.                445 Hoes Lane, P.O. Box 1331
  1376.                Piscataway, NJ 08855-1331
  1377.                Phone +1 908 562 3813
  1378.                Fax: +1 908 562 1571"
  1379.     ::= { 4 }
  1380.  
  1381. 5.2.5.  IANA Assigned Protocols
  1382.  
  1383. ianaAssigned PROTOCOL-IDENTIFIER
  1384.     PARAMETERS { }
  1385.     ATTRIBUTES { }
  1386.     DESCRIPTION
  1387.        "This branch contains protocols which do not conform easily to
  1388.        the hierarchical format utilized in the other link layer
  1389.        branches.  Usually, such a protocol 'almost' conforms to a
  1390.        particular 'well-known' identifier format, but additional
  1391.        criteria are used (e.g. configuration-based), making protocol
  1392.        identification difficult or impossible by examination of
  1393.        appropriate network traffic.  preventing the any 'well-known'
  1394.        protocol-identifier macro from being used.
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Bierman & Iddon             Standards Track                    [Page 25]
  1403.  
  1404. RFC 2074               RMON Protocol Identifiers            January 1997
  1405.  
  1406.  
  1407.        Sometimes well-known protocols are simply remapped to a different
  1408.        port number by one or more venders (e.g. SNMP). These protocols
  1409.        can be identified with the 'user-extensibility' feature of the
  1410.        protocolDirTable, and do not need special IANA
  1411.        assignments.
  1412.  
  1413.        A centrally located list of these enumerated protocols must be
  1414.        maintained to insure interoperability.
  1415.        (See section 3.2 for details on the document update procedure.)
  1416.        Support for new link-layers will be added explicitly, and only
  1417.        protocols which cannot possibly be represented in a better way
  1418.        will be considered as 'ianaEnumerated' protocols.
  1419.  
  1420.        IANA assigned protocols are identified by the base-layer-selector
  1421.        value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the
  1422.        integer value corresponding to the particular IANA protocol.
  1423.  
  1424.        Do not create children of this protocol unless you are sure that
  1425.        they cannot be handled by the more conventional link layers
  1426.        above."
  1427.     CHILDREN
  1428.        "Children of this protocol are identified by implementation-
  1429.        specific means, described (as best as possible) in the 'DECODING'
  1430.        clause within the protocol-variant-identifier macro for each
  1431.        enumerated protocol.
  1432.  
  1433.        For example, a protocolDirID-fragment value of:
  1434.           0.0.0.5.0.0.0.1
  1435.  
  1436.        defines the IPX protocol encapsulated directly in 802.3
  1437.  
  1438.        Children are named 'ianaAssigned' followed by the name or numeric
  1439.        of the particular IANA assigned protocol. The above
  1440.        example would be named:
  1441.  
  1442.           'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
  1443.  
  1444.     DECODING
  1445.        "The 'ianaAssigned' base layer is a pseudo-protocol and is not
  1446.        decoded."
  1447.     REFERENCE
  1448.        "Refer to individual PROTOCOL-IDENTIFIER macros for information
  1449.        on each child of the IANA assigned protocol."
  1450.     ::= { 5 }
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Bierman & Iddon             Standards Track                    [Page 26]
  1459.  
  1460. RFC 2074               RMON Protocol Identifiers            January 1997
  1461.  
  1462.  
  1463. 5.2.5.1.  IANA Assigned Protocol Identifiers
  1464.  
  1465.    The following protocol-variant-identifier macro declarations are used
  1466.    to identify the RMONMIB IANA assigned protocols in a proprietary way,
  1467.    by simple enumeration. Note that an additional four-octet layer
  1468.    identifier may be used for some enumerations (as with the 'vsnap'
  1469.    base-layer identifier). Refer to the 'CHILDREN' clause in the
  1470.    protocol-identifier macro for a particular protocol to determine the
  1471.    number of octets in the 'ianaAssigned' layer-identifier.
  1472.  
  1473. ipxOverRaw8023 PROTOCOL-IDENTIFIER
  1474.     VARIANT-OF  "ipx"
  1475.     PARAMETERS  { }
  1476.     ATTRIBUTES  { }
  1477.     DESCRIPTION
  1478.        "This pseudo-protocol describes an encapsulation of IPX over
  1479.        802.3, without a type field.
  1480.  
  1481.        Refer to the macro for IPX for additional information about this
  1482.        protocol."
  1483.     DECODING
  1484.        "Whenever the 802.3 header indicates LLC a set of protocol
  1485.        specific tests needs to be applied to determine whether this is a
  1486.        'raw8023' packet or a true 802.2 packet.  The nature of these
  1487.        tests depends on the active child protocols for 'raw8023' and is
  1488.        beyond the scope of this document."
  1489.     ::= { ianaAssigned 1 }
  1490.  
  1491. 5.3.  L3: Children of Base Protocol Identifiers
  1492.  
  1493.    Network layer protocol identifier macros contain additional
  1494.    information about the network layer, and is found immediately
  1495.    following a base layer-identifier in a protocol identifier.
  1496.  
  1497.    The ProtocolDirParameters supported at the network layer are
  1498.    'countsFragments(0)', and 'tracksSessions(1). An agent may choose to
  1499.    implement a subset of these parameters.
  1500.  
  1501.    The protocol-name should be used for the ProtocolDirDescr field.  The
  1502.    ProtocolDirType ATTRIBUTES used at the network layer are
  1503.    'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may
  1504.    choose to implement a subset of these attributes for each protocol,
  1505.    and therefore limit which tables the indicated protocol can be
  1506.    present (e.g.  protocol distribution, host, and matrix tables)..
  1507.  
  1508.    The following protocol-identifier macro declarations are given for
  1509.    example purposes only. They are not intended to constitute an
  1510.    exhaustive list or an authoritative source for any of the protocol
  1511.  
  1512.  
  1513.  
  1514. Bierman & Iddon             Standards Track                    [Page 27]
  1515.  
  1516. RFC 2074               RMON Protocol Identifiers            January 1997
  1517.  
  1518.  
  1519.    information given.  However, any protocol that can encapsulate other
  1520.    protocols must be documented here in order to encode the children
  1521.    identifiers into protocolDirID strings. Leaf protocols should be
  1522.    documented as well, but an implementation can identify a leaf
  1523.    protocol even if it isn't listed here (as long as the parent is
  1524.    documented).
  1525.  
  1526. 5.3.1.  IP
  1527.  
  1528. ip PROTOCOL-IDENTIFIER
  1529.     PARAMETERS {
  1530.           countsFragments(0)  -- This parameter applies to all child
  1531.                               -- protocols.
  1532.     }
  1533.     ATTRIBUTES {
  1534.         hasChildren(0),
  1535.         addressRecognitionCapable(1)
  1536.     }
  1537.     DESCRIPTION
  1538.        "The protocol identifiers for the Internet Protocol (IP). Note
  1539.        that IP may be encapsulated within itself, so more than one of
  1540.        the following identifiers may be present in a particular
  1541.        protocolDirID string."
  1542.     CHILDREN
  1543.        "Children of 'ip' are selected by the value in the Protocol field
  1544.        (one octet), as defined in the PROTOCOL NUMBERS table within the
  1545.        Assigned Numbers Document.
  1546.  
  1547.        The value of the Protocol field is encoded in an octet string as
  1548.        [ 0.0.0.a ], where 'a' is the protocol field .
  1549.  
  1550.        Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
  1551.        where 'a' is the protocol field value. For example, a
  1552.        protocolDirID-fragment value of:
  1553.           0.0.0.1.0.0.8.0.0.0.0.1
  1554.  
  1555.        defines an encapsulation of ICMP (ether2.ip.icmp)"
  1556.     ADDRESS-FORMAT
  1557.        "4 octets of the IP address, in network byte order.  Each ip
  1558.        packet contains two addresses, the source address and the
  1559.        destination address."
  1560.     DECODING
  1561.        "Note: ether2/ip/ipip4/udp is a different protocolDirID than
  1562.        ether2/ip/udp, as identified in the protocolDirTable. As such,
  1563.        two different local protocol index values will be assigned by the
  1564.        agent. E.g. (full INDEX values shown):
  1565.         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
  1566.         ether2/ip/udp       12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
  1567.  
  1568.  
  1569.  
  1570. Bierman & Iddon             Standards Track                    [Page 28]
  1571.  
  1572. RFC 2074               RMON Protocol Identifiers            January 1997
  1573.  
  1574.  
  1575.     REFERENCE
  1576.        "RFC 791 [RFC791] defines the Internet Protocol; The following
  1577.        URL defines the authoritative repository for the PROTOCOL NUMBERS
  1578.        Table:
  1579.  
  1580.           ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
  1581.     ::= {
  1582.           ether2 0x0800,
  1583.           llc 0x06,
  1584.           snap 0x0800,
  1585.           ip 4,
  1586.           ip 94
  1587.     }
  1588.  
  1589. 5.3.2.  IPX
  1590.  
  1591. ipx PROTOCOL-IDENTIFIER
  1592.     PARAMETERS { }
  1593.     ATTRIBUTES {
  1594.          hasChildren(0),
  1595.          addressRecognitionCapable(1)
  1596.     }
  1597.     DESCRIPTION
  1598.        "Novell IPX"
  1599.     CHILDREN
  1600.        "Children of IPX are defined by the 16 bit value of the
  1601.        Destination Socket field.  The value is encoded into an octet
  1602.        string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
  1603.        order encodings of the MSB and LSB of the destination socket
  1604.        field."
  1605.     ADDRESS-FORMAT
  1606.        "4 bytes of Network number followed by the 6 bytes Host address
  1607.        each in network byte order".
  1608.     REFERENCE
  1609.        "The IPX protocol is defined by the Novell Corporation
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Bierman & Iddon             Standards Track                    [Page 29]
  1627.  
  1628. RFC 2074               RMON Protocol Identifiers            January 1997
  1629.  
  1630.  
  1631.        A complete description of IPX may be secured at the following
  1632.        address:
  1633.               Novell, Inc.
  1634.               122 East 1700 South
  1635.               P. O. Box 5900
  1636.               Provo, Utah 84601 USA
  1637.               800 526 5463
  1638.               Novell Part # 883-000780-001"
  1639.     ::= {
  1640.         ether2     0x8137,           -- 0.0.129.55
  1641.         llc        0xe0e003,         -- 0.224.224.3
  1642.         snap       0x8137,           -- 0.0.129.55
  1643.         ianaAssigned 0x1               -- 0.0.0.1   (ipxOverRaw8023)
  1644.     }
  1645.  
  1646. 5.3.3.  ARP
  1647.  
  1648. arp PROTOCOL-IDENTIFIER
  1649.     PARAMETERS { }
  1650.     ATTRIBUTES { }
  1651.     DESCRIPTION
  1652.        "An Address Resolution Protocol message (request or response).
  1653.        This protocol does not include Reverse ARP (RARP) packets, which
  1654.        are counted separately."
  1655.     REFERENCE
  1656.        "RFC 826 [RFC826] defines the Address Resolution Protocol."
  1657.     ::= {
  1658.         ether2 0x806,   -- [ 0.0.8.6 ]
  1659.         snap 0x806
  1660.     }
  1661.  
  1662. 5.3.4.  IDP
  1663.  
  1664. idp PROTOCOL-IDENTIFIER
  1665.     PARAMETERS { }
  1666.     ATTRIBUTES {
  1667.          hasChildren(0),
  1668.          addressRecognitionCapable(1)
  1669.     }
  1670.     DESCRIPTION
  1671.        "Xerox IDP"
  1672.     CHILDREN
  1673.        "Children of IDP are defined by the 8 bit value of the Packet
  1674.        type field.  The value is encoded into an octet string as [
  1675.        0.0.0.a ], where 'a' is the value of the packet type field in
  1676.        network byte order."
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Bierman & Iddon             Standards Track                    [Page 30]
  1683.  
  1684. RFC 2074               RMON Protocol Identifiers            January 1997
  1685.  
  1686.  
  1687.     ADDRESS-FORMAT
  1688.        "4 bytes of Network number followed by the 6 bytes Host address
  1689.        each in network byte order".
  1690.     REFERENCE
  1691.        "Xerox Corporation, Document XNSS 028112, 1981"
  1692.     ::=  {
  1693.        ether2  0x600,     -- [ 0.0.6.0 ]
  1694.        snap    0x600
  1695.     }
  1696.  
  1697. 5.3.5.  AppleTalk ARP
  1698.  
  1699. atalkarp PROTOCOL-IDENTIFIER
  1700.     PARAMETERS { }
  1701.     ATTRIBUTES { }
  1702.     DESCRIPTION
  1703.        "AppleTalk Address Resolution Protocol."
  1704.     REFERENCE
  1705.        "AppleTalk Phase 2 Protocol Specification, document ADPA
  1706.        #C0144LL/A."
  1707.     ::=   {
  1708.       ether2 0x80f3,  --  [ 0.0.128.243 ]
  1709.       vsnap(0x080007) 0x80f3
  1710.     }
  1711.  
  1712. 5.3.6.  AppleTalk
  1713.  
  1714. atalk PROTOCOL-IDENTIFIER
  1715.     PARAMETERS { }
  1716.     ATTRIBUTES {
  1717.         hasChildren(0),
  1718.         addressRecognitionCapable(1)
  1719.     }
  1720.     DESCRIPTION
  1721.        "AppleTalk Protocol."
  1722.     CHILDREN
  1723.        "Children of ATALK are defined by the 8 bit value of the DDP type
  1724.        field.  The value is encoded into an octet string as [ 0.0.0.a ],
  1725.        where 'a' is the value of the DDP type field in network byte
  1726.        order."
  1727.     ADDRESS-FORMAT
  1728.        "2 bytes of Network number followed by 1 byte of node id each in
  1729.        network byte order".
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Bierman & Iddon             Standards Track                    [Page 31]
  1739.  
  1740. RFC 2074               RMON Protocol Identifiers            January 1997
  1741.  
  1742.  
  1743.     REFERENCE
  1744.        "AppleTalk Phase 2 Protocol Specification, document ADPA
  1745.        #C0144LL/A."
  1746.     ::=   {
  1747.       ether2  0x809b,   -- [ 0.0.128.155 ]
  1748.       vsnap(0x080007) 0x809b
  1749.     }
  1750.  
  1751. 5.4.  L4: Children of L3 Protocols
  1752.  
  1753. 5.4.1.  ICMP
  1754.  
  1755. icmp PROTOCOL-IDENTIFIER
  1756.     PARAMETERS { }
  1757.     ATTRIBUTES { }
  1758.     DESCRIPTION
  1759.        "Internet Message Control Protocol."
  1760.     REFERENCE
  1761.        "RFC 792 [RFC792] defines the Internet Control Message Protocol."
  1762.     ::= { ip 1 }
  1763.  
  1764. 5.4.2.  TCP
  1765.  
  1766. tcp  PROTOCOL-IDENTIFIER
  1767.     PARAMETERS { }
  1768.     ATTRIBUTES {
  1769.          hasChildren(0)
  1770.     }
  1771.     DESCRIPTION
  1772.        "Transmission Control Protocol."
  1773.     CHILDREN
  1774.        "Children of TCP are identified by the 16 bit Destination Port
  1775.        value as specified in RFC 793. They are encoded as [ 0.0.a.b],
  1776.        where 'a' is the MSB and 'b' is the LSB of the Destination Port
  1777.        value. Both bytes are encoded in network byte order.  For
  1778.        example, a protocolDirId-fragment of:
  1779.            0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
  1780.  
  1781.        identifies an encapsulation of the telnet protocol
  1782.        (ether2.ip.tcp.telnet)"
  1783.     REFERENCE
  1784.        "RFC 793 [RFC793] defines the Transmission Control Protocol.
  1785.  
  1786.        The following URL defines the authoritative repository for
  1787.        reserved and registered TCP port values:
  1788.  
  1789.          ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
  1790.     ::=  { ip 6 }
  1791.  
  1792.  
  1793.  
  1794. Bierman & Iddon             Standards Track                    [Page 32]
  1795.  
  1796. RFC 2074               RMON Protocol Identifiers            January 1997
  1797.  
  1798.  
  1799. 5.4.3.  UDP
  1800.  
  1801. udp  PROTOCOL-IDENTIFIER
  1802.     PARAMETERS { }
  1803.     ATTRIBUTES {
  1804.          hasChildren(0)
  1805.     }
  1806.     DESCRIPTION
  1807.        "User Datagram Protocol."
  1808.     CHILDREN
  1809.        "Children of UDP are identified by the 16 bit Destination Port
  1810.        value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
  1811.        where 'a' is the MSB and 'b' is the LSB of the Destination Port
  1812.        value. Both bytes are encoded in network byte order.  For
  1813.        example, a protocolDirId-fragment of:
  1814.            0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
  1815.  
  1816.        identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
  1817.     REFERENCE
  1818.        "RFC 768 [RFC768] defines the User Datagram Protocol.
  1819.  
  1820.        The following URL defines the authoritative repository for
  1821.        reserved and registered UDP port values:
  1822.  
  1823.          ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
  1824.    ::= { ip 17 }
  1825.  
  1826. 5.5.  L5: Application Layer Protocols
  1827.  
  1828. 5.5.1.  FTP
  1829.  
  1830. 5.5.1.1.  FTP-DATA
  1831.  
  1832. ftp-data PROTOCOL-IDENTIFIER
  1833.     PARAMETERS { }
  1834.     ATTRIBUTES { }
  1835.     DESCRIPTION
  1836.        "The File Transfer Protocol Data Port; the FTP Server process
  1837.        default data-connection port. "
  1838.     REFERENCE
  1839.        "RFC 959 [RFC959] defines the File Transfer Protocol.  Refer to
  1840.        section 3.2 of [RFC959] for details on FTP data connections."
  1841.     ::= { tcp 20 }
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Bierman & Iddon             Standards Track                    [Page 33]
  1851.  
  1852. RFC 2074               RMON Protocol Identifiers            January 1997
  1853.  
  1854.  
  1855. 5.5.1.2.  FTP Control
  1856.  
  1857. ftp PROTOCOL-IDENTIFIER
  1858.     PARAMETERS { }
  1859.     ATTRIBUTES { }
  1860.     DESCRIPTION
  1861.        "The File Transfer Protocol Control Port; An FTP client initiates
  1862.        an FTP control connection by sending FTP commands from user port
  1863.        (U) to this port."
  1864.     REFERENCE
  1865.        "RFC 959 [RFC959] defines the File Transfer Protocol."
  1866.     ::= { tcp 21 }
  1867.  
  1868. 5.5.2.  Telnet
  1869.  
  1870. telnet PROTOCOL-IDENTIFIER
  1871.     PARAMETERS { }
  1872.     ATTRIBUTES { }
  1873.     DESCRIPTION
  1874.        "The Telnet Protocol; The purpose of the TELNET Protocol is to
  1875.        provide a fairly general, bi-directional, eight-bit byte oriented
  1876.        communications facility.  Its primary goal is to allow a standard
  1877.        method of interfacing terminal devices and terminal-oriented
  1878.        processes to each other. "
  1879.     REFERENCE
  1880.        "RFC 854 [RFC854] defines the basic Telnet Protocol."
  1881.     ::= { tcp 23 }
  1882.  
  1883. 5.5.3.  SMTP
  1884.  
  1885. smtp PROTOCOL-IDENTIFIER
  1886.     PARAMETERS { }
  1887.     ATTRIBUTES { }
  1888.     DESCRIPTION
  1889.        "The Simple Mail Transfer Protocol; SMTP control and data
  1890.        messages are sent on this port."
  1891.     REFERENCE
  1892.        "RFC 821 [RFC821] defines the basic Simple Mail Transfer
  1893.        Protocol."
  1894.     ::= { tcp 25 }
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Bierman & Iddon             Standards Track                    [Page 34]
  1907.  
  1908. RFC 2074               RMON Protocol Identifiers            January 1997
  1909.  
  1910.  
  1911. 5.5.4.  DNS
  1912.  
  1913. domain PROTOCOL-IDENTIFIER
  1914.     PARAMETERS { }
  1915.     ATTRIBUTES { }
  1916.     DESCRIPTION
  1917.        "Domain Name Service Protocol; DNS may be transported by either
  1918.        UDP [RFC768] or TCP [RFC793].  If the transport is UDP, DNS
  1919.        requests restricted to 512 bytes in length may be sent to this
  1920.        port."
  1921.     REFERENCE
  1922.        "RFC 1035 [RFC1035] defines the Bootstrap Protocol."
  1923.     ::= { udp 53,
  1924.           tcp 53  }
  1925.  
  1926. 5.5.5.  BOOTP
  1927.  
  1928. 5.5.5.1.  Bootstrap Server Protocol
  1929.  
  1930. bootps PROTOCOL-IDENTIFIER
  1931.     PARAMETERS { }
  1932.     ATTRIBUTES { }
  1933.     DESCRIPTION
  1934.        "Bootstrap Protocol Server Protocol; BOOTP Clients send requests
  1935.        (usually broadcast) to the bootps port."
  1936.     REFERENCE
  1937.        "RFC 951 [RFC951] defines the Bootstrap Protocol."
  1938.     ::= { udp 67 }
  1939.  
  1940. 5.5.5.2.  Bootstrap Client Protocol
  1941.  
  1942. bootpc PROTOCOL-IDENTIFIER
  1943.     PARAMETERS { }
  1944.     ATTRIBUTES { }
  1945.     DESCRIPTION
  1946.        "Bootstrap Protocol Client Protocol; BOOTP Server replies are
  1947.        sent to the BOOTP Client using this destination port."
  1948.     REFERENCE
  1949.        "RFC 951 [RFC951] defines the Bootstrap Protocol."
  1950.     ::= { udp 68 }
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Bierman & Iddon             Standards Track                    [Page 35]
  1963.  
  1964. RFC 2074               RMON Protocol Identifiers            January 1997
  1965.  
  1966.  
  1967. 5.5.6.  TFTP
  1968.  
  1969. tftp PROTOCOL-IDENTIFIER
  1970.     PARAMETERS {
  1971.         tracksSessions(1)
  1972.     }
  1973.     ATTRIBUTES { }
  1974.     DESCRIPTION
  1975.        "Trivial File Transfer Protocol; Only the first packet of each
  1976.        TFTP transaction will be sent to port 69. If the tracksSessions
  1977.        attribute is set, then packets for each TFTP transaction will be
  1978.        attributed to tftp, instead of the unregistered port numbers that
  1979.        will be encoded in subsequent packets."
  1980.     REFERENCE
  1981.        "RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
  1982.        1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
  1983.        defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
  1984.        TFTP Timeout Interval and Transfer Size Options."
  1985.  
  1986.     ::= { udp 69 }
  1987.  
  1988. 5.5.7.  HTTP
  1989.  
  1990. www-http PROTOCOL-IDENTIFIER
  1991.     PARAMETERS { }
  1992.     ATTRIBUTES { }
  1993.     DESCRIPTION
  1994.        "Hypertext Transfer Protocol; "
  1995.     REFERENCE
  1996.        "RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
  1997.        (HTTP/1.0)."
  1998.     ::= { tcp 80 }
  1999.  
  2000. 5.5.8.  POP3
  2001.  
  2002. pop3 PROTOCOL-IDENTIFIER
  2003.     PARAMETERS { }
  2004.     ATTRIBUTES { }
  2005.     DESCRIPTION
  2006.        "Post Office Protocol -- Version 3. Clients establish connections
  2007.        with POP3 servers by using this destination port number."
  2008.     REFERENCE
  2009.        "RFC 1725 [RFC1725] defines Version 3 of the Post Office
  2010.        Protocol."
  2011.     ::= { tcp 110 }
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Bierman & Iddon             Standards Track                    [Page 36]
  2019.  
  2020. RFC 2074               RMON Protocol Identifiers            January 1997
  2021.  
  2022.  
  2023. 5.5.9.  SUNRPC
  2024.  
  2025. sunrpc PROTOCOL-IDENTIFIER
  2026.     PARAMETERS { }
  2027.     ATTRIBUTES {
  2028.                 hasChildren(0)   -- port mapper function numbers
  2029.         }
  2030.     DESCRIPTION
  2031.        "SUN Remote Procedure Call Protocol. Port mapper function
  2032.        requests are sent to this destination port."
  2033.     CHILDREN
  2034.        Specific RPC functions are represented as children of the sunrpc
  2035.        protocol. Each 'RPC function protocol' is identified by its
  2036.        function number assignment. RPC function number assignments are
  2037.        defined by different naming authorities, depending of the
  2038.        function identifier value.
  2039.        From [RFC1831]:
  2040.  
  2041.        Program numbers are given out in groups of hexadecimal 20000000
  2042.        (decimal 536870912) according to the following chart:
  2043.  
  2044.                      0 - 1fffffff   defined by rpc@sun.com
  2045.               20000000 - 3fffffff   defined by user
  2046.               40000000 - 5fffffff   transient
  2047.               60000000 - 7fffffff   reserved
  2048.               80000000 - 9fffffff   reserved
  2049.               a0000000 - bfffffff   reserved
  2050.               c0000000 - dfffffff   reserved
  2051.               e0000000 - ffffffff   reserved
  2052.  
  2053.        Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
  2054.        identifier component for 'sunrpc', followed by [ a.b.c.d ], where
  2055.        a.b.c.d is the 32 bit binary RPC program number encoded in
  2056.        network byte order.  For example, a protocolDirID-fragment value
  2057.        of:
  2058.            0.0.0.111.0.1.134.163
  2059.  
  2060.        defines the NFS function (and protocol).
  2061.  
  2062.        Children are named as 'sunrpc' followed by the RPC function
  2063.        number in base 10 format. For example, NFS would be named:
  2064.            'sunrpc 100003'.
  2065.     REFERENCE
  2066.        "RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
  2067.        Version 2.  The authoritative list of RPC Functions is identified
  2068.        by the URL:
  2069.            ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
  2070.     ::= { udp 111 }
  2071.  
  2072.  
  2073.  
  2074. Bierman & Iddon             Standards Track                    [Page 37]
  2075.  
  2076. RFC 2074               RMON Protocol Identifiers            January 1997
  2077.  
  2078.  
  2079. 5.5.10.  NFS
  2080.  
  2081. nfs  PROTOCOL-IDENTIFIER
  2082.     PARAMETERS {
  2083.                 countsFragments(0)
  2084.         }
  2085.     ATTRIBUTES { }
  2086.     DESCRIPTION
  2087.        "Sun Network File System (NFS);"
  2088.     DECODING
  2089.        "The first packet in an NFS transaction is sent to the port-
  2090.        mapper, and therefore decoded statically by monitoring RFC
  2091.        portmap requests [RFC1831]. Any subsequent NFS fragments must be
  2092.        decoded and correctly identified by 'remembering' the port
  2093.        assignments used in each RPC function call (as identified
  2094.        according to the procedures in the RPC Specification Version 2
  2095.        [RFC1831]).
  2096.  
  2097.        The 'countsFragments(0)' PARAMETER bit is used to indicate
  2098.        whether the probe can (and should) monitor portmapper activity to
  2099.        correctly attribute all NFS packets."
  2100.     REFERENCE
  2101.        "The NFS Version 3 Protocol Specification is defined in RFC 1813
  2102.        [RFC1813]."
  2103.     ::= {
  2104.         sunrpc 100003           --  [0.1.134.163]
  2105.     }
  2106.  
  2107. 5.5.11.  SNMP
  2108.  
  2109. 5.5.11.1.  SNMP Request/Response
  2110.  
  2111. snmp  PROTOCOL-IDENTIFIER
  2112.     PARAMETERS { }
  2113.     ATTRIBUTES { }
  2114.     DESCRIPTION
  2115.        "Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
  2116.        protocol versions. Does not include SNMP trap packets."
  2117.     REFERENCE
  2118.        "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
  2119.        protocol is defined in RFC 1905 [RFC1905].  Transport mappings
  2120.        are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
  2121.        [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
  2122.     ::= {
  2123.         udp 161,
  2124.         ipx 0x900f,   -- [ 0.0.144.15 ]
  2125.         atalk 8
  2126.     }
  2127.  
  2128.  
  2129.  
  2130. Bierman & Iddon             Standards Track                    [Page 38]
  2131.  
  2132. RFC 2074               RMON Protocol Identifiers            January 1997
  2133.  
  2134.  
  2135. 5.5.11.2.  SNMP Trap
  2136.  
  2137. snmptrap PROTOCOL-IDENTIFIER
  2138.     PARAMETERS { }
  2139.     ATTRIBUTES { }
  2140.     DESCRIPTION
  2141.        "Simple Network Management Protocol Trap Port."
  2142.     REFERENCE
  2143.        "The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
  2144.        protocol is defined in RFC 1905 [RFC1905].  Transport mappings
  2145.        are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
  2146.        [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
  2147.     ::= {
  2148.         udp 162,
  2149.         ipx 0x9010,
  2150.         atalk 9
  2151.     }
  2152.  
  2153. 6.  Acknowledgements
  2154.  
  2155.    This document was produced by the IETF RMONMIB Working Group.
  2156.  
  2157.    The authors wish to thank the following people for their
  2158.    contributions to this document:
  2159.  
  2160.         Anil Singhal
  2161.         Frontier Software Development, Inc.
  2162.  
  2163.         Jeanne Haney
  2164.         Bay Networks
  2165.  
  2166.         Dan Hansen
  2167.         Network General Corp.
  2168.  
  2169.  
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Bierman & Iddon             Standards Track                    [Page 39]
  2187.  
  2188. RFC 2074               RMON Protocol Identifiers            January 1997
  2189.  
  2190.  
  2191. 7.  References
  2192.  
  2193. [RFC768]
  2194.      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  2195.      USC/Information Sciences Institute, August 1980.
  2196.  
  2197. [RFC791]
  2198.      Postel, J., ed., "Internet Protocol - DARPA Internet Program
  2199.      Protocol Specification", STD 5, RFC 791, USC/Information Sciences
  2200.      Institute, September 1981.
  2201.  
  2202. [RFC792]
  2203.      Postel, J., "Internet Control Message Protocol - DARPA Internet
  2204.      Program Protocol Specification", STD 5, RFC 792, USC/Information
  2205.      Sciences Institute, September 1981.
  2206.  
  2207. [RFC793]
  2208.      Postel, J., "Transmission Control Protocol - DARPA Internet Program
  2209.      Protocol Specification", STD 5, RFC 793, USC/Information Sciences
  2210.      Institute, September 1981.
  2211.  
  2212. [RFC821]
  2213.      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  2214.      USC/Information Sciences Institute, August 1982.
  2215.  
  2216. [RFC826]
  2217.      Plummer, D., "An Ethernet Address Resolution Protocol or
  2218.      "Converting Network Protocol Addresses to 48-bit Ethernet Addresses
  2219.      for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS,
  2220.      November 1982.
  2221.  
  2222. [RFC854]
  2223.      Postel, J. and J. Reynolds, "Telnet Protocol Specification",
  2224.      STD 8, RFC 854, ISI, May 1983.
  2225.  
  2226. [RFC894]
  2227.      Hornig, C., "A Standard for the Transmission of IP Datagrams over
  2228.      Ethernet Networks", RFC 894, Symbolics, April 1984.
  2229.  
  2230. [RFC951]
  2231.      Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
  2232.      Stanford and SUN Microsytems, September 1985.
  2233.  
  2234. [RFC959]
  2235.      Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8,
  2236.      RFC 959, USC/Information Sciences Institute, October 1985.
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Bierman & Iddon             Standards Track                    [Page 40]
  2243.  
  2244. RFC 2074               RMON Protocol Identifiers            January 1997
  2245.  
  2246.  
  2247. [RFC1035]
  2248.      Mockapetris, P., "Domain Names - Implementation and Specification",
  2249.      STD 13, RFC 1035, USC/Information Sciences Institute, November
  2250.      1987.
  2251.  
  2252. [RFC1157]
  2253.      Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
  2254.      Management Protocol", STD 15, RFC 1157, SNMP Research,
  2255.      Performance Systems International, MIT Laboratory for Computer
  2256.      Science, May 1990.
  2257.  
  2258. [RFC1213]
  2259.      McCloghrie, K., and M. Rose, Editors, "Management Information Base
  2260.      for Network Management of TCP/IP-based internets: MIB-II", STD 17,
  2261.      RFC 1213, Hughes LAN Systems, Performance Systems International,
  2262.      March 1991.
  2263.  
  2264. [RFC1350]
  2265.      Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
  2266.      1992.
  2267.  
  2268. [RFC1419]
  2269.      Minshall, G., and M.  Ritter, "SNMP over AppleTalk", RFC 1419,
  2270.      Novell, Inc., Apple Computer, Inc., March 1993.
  2271.  
  2272. [RFC1420]
  2273.      Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
  2274.  
  2275. [RFC1700]
  2276.      Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  2277.      USC/Information Sciences Institute, October 1994.
  2278.  
  2279. [RFC1725]
  2280.      Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
  2281.      1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
  2282.  
  2283. [RFC1757]
  2284.      S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
  2285.      Mellon University, February 1995.
  2286.  
  2287. [RFC1782]
  2288.      Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782,
  2289.      Xylogics, Inc., Hewlett Packard Co., March 1995.
  2290.  
  2291. [RFC1783]
  2292.      Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783,
  2293.      Xylogics, Inc., Hewlett Packard Co., March 1995.
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Bierman & Iddon             Standards Track                    [Page 41]
  2299.  
  2300. RFC 2074               RMON Protocol Identifiers            January 1997
  2301.  
  2302.  
  2303. [RFC1784]
  2304.      Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
  2305.      Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
  2306.      1995.
  2307.  
  2308. [RFC1800]
  2309.      Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
  2310.      RFC 1920, IAB, March 1996.
  2311.  
  2312. [RFC1831]
  2313.      Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
  2314.      1831, Sun Microsystems, Inc., August 1995.
  2315.  
  2316. [RFC1902]
  2317.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  2318.      S. Waldbusser, "Structure of Management Information for version 2
  2319.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  2320.      January 1996.
  2321.  
  2322. [RFC1903]
  2323.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  2324.      S. Waldbusser, "Textual Conventions for version 2 of the Simple
  2325.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  2326.  
  2327. [RFC1904]
  2328.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  2329.      S. Waldbusser, "Conformance Statements for version 2 of the Simple
  2330.      Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
  2331.  
  2332. [RFC1905]
  2333.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  2334.      S. Waldbusser, "Protocol Operations for version 2 of the Simple
  2335.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  2336.  
  2337. [RFC1906]
  2338.      SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
  2339.      Waldbusser, "Transport Mappings for Version 2 of the Simple Network
  2340.      Management Protocol (SNMPv2)", RFC 1906, January 1996.
  2341.  
  2342. [RFC1945]
  2343.      Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
  2344.      HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995.
  2345.  
  2346. [RMON2]
  2347.      S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
  2348.      ietf-rmonmib-rmon2-03.txt, International Network Services, January
  2349.      1996.
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Bierman & Iddon             Standards Track                    [Page 42]
  2355.  
  2356. RFC 2074               RMON Protocol Identifiers            January 1997
  2357.  
  2358.  
  2359. 8.  Security Considerations
  2360.  
  2361.    Security issues are not discussed in this memo.
  2362.  
  2363. 9.  Authors' Addresses
  2364.  
  2365.    Andy Bierman
  2366.    Cisco Systems, Inc.
  2367.    170 West Tasman Drive
  2368.    San Jose, CA 95134
  2369.  
  2370.    Phone: 408-527-3711
  2371.    EMail: abierman@cisco.com
  2372.  
  2373.  
  2374.    Robin Iddon
  2375.    3Com/AXON
  2376.    40/50 Blackfrias Street
  2377.    Edinburgh, UK
  2378.  
  2379.    Phone: +44 131.558.3888
  2380.    EMail: robin_iddon@3mail.3com.com
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Bierman & Iddon             Standards Track                    [Page 43]
  2411.  
  2412.