rfc2074.txt

RFC 的详细文档！

   (protocolDirParameters) which contains a corresponding number of 1-
   octet protocol-specific parameters, one for each 4-octet layer-
   identifier in the first string.

   A protocol layer is normally identified by a single 32-bit value.
   Each layer-identifier is encoded in the ProtocolDirID OCTET STRING
   INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent
   each byte of the 32-bit value in network byte order.  If a particular
   protocol layer cannot be encoded into 32 bits, (except for the
   'vsnap' base layer) then it must be defined as a 'ianaAssigned'
   protocol (see below for details on IANA assigned protocols).

   The following figures show the differences between the OBJECT
   IDENTIFIER and OCTET STRING encoding of the protocol identifier
   string.


                   Fig. 1a
         protocolDirTable INDEX Format
         -----------------------------

     +---+--------------------------+---+---------------+
     | c !                          | c !  protocolDir  |
     | n !  protocolDirID           | n !  Parameters   |
     | t !                          | t !               |
     +---+--------------------------+---+---------------+













Bierman & Iddon             Standards Track                     [Page 7]

RFC 2074               RMON Protocol Identifiers            January 1997


                   Fig. 1b
         protocolDirTable OCTET STRING Format
         ------------------------------------

      protocolDirID
     +----------------------------------------+
     |                                        |
     |              4 * N octets              |
     |                                        |
     +----------------------------------------+

     protocolDirParameters
     +----------+
     |          |
     | N octets |
     |          |
     +----------+

                    Fig. 1c
        protocolDirTable INDEX Format Example
        -------------------------------------

     protocolDirID                   protocolDirParameters
     +---+--------+--------+--------+--------+---+---+---+---+---+
     | c |  proto |  proto |  proto |  proto | c |par|par|par|par|
     | n |  base  |    L3  |   L4   |   L5   | n |ba-| L3| L4| L5|
     | t |(+flags)|        |        |        | t |se |   |   |   |
     +---+--------+--------+--------+--------+---+---+---+---+---+ subOID
     | 1 | 4 or 8 |    4   |    4   |    4   | 1 |1/2| 1 | 1 | 1 | count

     where N is the number of protocol-layer-identifiers required
     for the entire encapsulation of the named protocol. Note that
     the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
     All other protocol layers are either encoded into 4 sub-identifiers
     or encoded as a 'ianaAssigned' protocol.
















Bierman & Iddon             Standards Track                     [Page 8]

RFC 2074               RMON Protocol Identifiers            January 1997


                    Fig. 1d
       protocolDirTable OCTET STRING Format Example
       --------------------------------------------

     protocolDirID
     +--------+--------+--------+--------+
     |  proto |  proto |  proto |  proto |
     |   base |    L3  |   L4   |   L5   |
     |        |        |        |        |
     +--------+--------+--------+--------+ octet
     | 4 or 8 |    4   |    4   |    4   | count


     protocolDirParameters
     +---+---+---+---+
     |par|par|par|par|
     |ba-| L3| L4| L5|
     |se |   |   |   |
     +---+---+---+---+ octet
     |1/2| 1 | 1 | 1 | count

     where N is the number of protocol-layer-identifiers required
     for the entire encapsulation of the named protocol. Note that
     the 'vsnap' base layer identifier is encoded into 8
     protocolDirID sub-identifiers and 2 protocolDirParameters
     sub-identifiers.

   Although this example indicates four encapsulated protocols, in
   practice, any non-zero number of layer-identifiers may be present,
   theoretically limited only by OBJECT IDENTIFIER length restrictions,
   as specified in section 3.5 of RFC 1902 [RFC1902].

   Note that these two strings would not be concatenated together if
   ever returned in a GetResponse PDU, since they are different MIB
   objects.  However, protocolDirID and protocolDirParameters are not
   currently readable MIB objects.

4.1.  ProtocolDirTable INDEX Format Examples

    -- HTTP; fragments counted from IP and above
    ether2.ip.tcp.www-http =
       16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0

    -- SNMP over UDP/IP over SNAP
    snap.ip.udp.snmp =
       16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0





Bierman & Iddon             Standards Track                     [Page 9]

RFC 2074               RMON Protocol Identifiers            January 1997


    -- SNMP over IPX over SNAP
    snap.ipx.snmp =
       12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0

    -- SNMP over IPX over raw8023
    -- ianaAssigned(ipxOverRaw8023(1)).snmp =
       12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0

    -- IPX over LLC
    llc.ipx =
       8.0.0.0.2.0.224.224.3.2.0.0

    -- SNMP over UDP/IP over any link layer
    -- wildcard-ether2.ip.udp.snmp
       16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0

    -- IP over any link layer; base encoding is IP over ether2
    -- wildcard-ether2.ip
       8.1.0.0.1.0.0.8.0.2.0.0

   -- AppleTalk Phase 2 over ether2
   -- ether2.atalk
      8.0.0.0.1.0.0.128.155.2.0.0

   -- AppleTalk Phase 2 over vsnap
   -- vsnap(apple).atalk
      12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0

4.2.  Protocol Identifier Macro Format

   The following example is meant to introduce the protocol-identifier
   macro. (The syntax is not quite ASN.1.) This macro is used to
   represent both protocols and protocol-variants.

   If the 'VariantOfPart' component of the macro is present, then the
   macro represents a protocol-variant instead of a protocol.  A
   protocol- variant-identifier is used only for IANA assigned
   protocols, enumerated under the 'ianaAssigned' base-layer.













Bierman & Iddon             Standards Track                    [Page 10]

RFC 2074               RMON Protocol Identifiers            January 1997


     RMON-PROTOCOL-IDENTIFIER MACRO ::=
     BEGIN
             PIMacroName "PROTOCOL-IDENTIFIER"
                     VariantOfPart
                     "PARAMETERS"   ParamPart
                     "ATTRIBUTES"   AttrPart
                     "DESCRIPTION"  Text
                     ChildDescrPart
                     AddrDescrPart
                     DecodeDescrPart
                     ReferPart
             "::=" "{" EncapsPart "}"

             PIMacroName ::=
                 identifier

             VariantOfPart ::=
                 "VARIANT-OF" identifier | empty

             ParamPart ::=
                 "{" ParamList "}"

             ParamList ::=
                 Params | empty

             Params ::=
                 Param | Params "," Param

             Param ::=
                 identifier "(" nonNegativeNumber ")"

             AttrPart ::=
                 "{" AttrList "}"

             AttrList ::=
                 Attrs | empty

             Attrs ::=
                 Attr | Attrs "," Attr

             Attr ::=
                 identifier "(" nonNegativeNumber ")"

             ChildDescrPart ::=
                 "CHILDREN" Text | empty

             AddrDescrPart ::=
                 "ADDRESS-FORMAT" Text | empty



Bierman & Iddon             Standards Track                    [Page 11]

RFC 2074               RMON Protocol Identifiers            January 1997


             DecodeDescrPart ::=
                 "DECODING" Text | empty

             ReferPart ::=
                 "REFERENCE" Text | empty

             EncapsPart ::=
                 "{" Encaps "}"

             Encaps ::=
                 Encap | Encaps "," Encap

             Encap ::=
                 BaseEncap | NormalEncap | VsnapEncap | IanaEncap

             BaseEncap ::=
                 nonNegativeNumber

             NormalEncap ::=
                 identifier nonNegativeNumber

             VsnapEncap ::=
                 identifier "(" nonNegativeNumber ")" nonNegativeNumber

             IanaEncap ::=
                 "ianaAssigned" nonNegativeNumber
                 | "ianaAssigned" identifier
                 | "ianaAssigned" identifier "(" nonNegativeNumber ")"

             Text ::=
                 """" string """"
     END

4.2.1.  Mapping of the Protocol Name

   The 'PIMacroName' value should be a lower-case ASCII string, and
   contain the name or acronym identifying the protocol.  NMS
   applications may treat protocol names as case-insensitive strings,
   and agent implementations must make sure the protocolDirTable does
   not contain any instances of the protocolDirDescr object which differ
   only in the case of one of more letters (if the identifiers are
   intended to represent different protocols).

   It is possible that different encapsulations of the same protocol
   (which are represented by different entries in the protocolDirTable)
   will be assigned the same protocol name.





Bierman & Iddon             Standards Track                    [Page 12]

RFC 2074               RMON Protocol Identifiers            January 1997


   A protocol name should match the "most well-known" name or acronym
   for the indicated protocol.  For example, the document indicated by
   the URL:

       ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers

   defines IP Protocol field values, so protocol-identifier macros for
   children of IP should be given names consistent with the protocol
   names found in this authoritative document.

4.2.2.  Mapping of the VARIANT-OF Clause

   This clause is present for IANA assigned protocols only.  It
   identifies the protocol-identifier macro that most closely represents
   this particular protocol, and is known as the "reference protocol".
   (A protocol-identifier macro must exist for the reference protocol.)
   When this clause is present in a protocol-identifier macro, the macro
   is called a 'protocol-variant-identifier'.

   Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-
   identifier macro should not be duplicated in the protocol-variant-
   identifier macro, if the 'variant' protocols' semantics are identical
   for a given clause.

   Since the PARAMETERS and ATTRIBUTES clauses must be present in a
   protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
   "PARAMETERS {}") must be present in a protocol-variant-identifier
   macro, and the 'ParamPart' and 'AttrPart' found in the reference
   protocol- identifier macro examined instead.