rfc2074.txt

RFC 的详细文档！

   Note that if a 'ianaAssigned' protocol is defined that is not a
   variant of any other documented protocol, then the protocol-
   identifier macro should be used instead of the protocol-variant-
   identifier version of the macro.

4.2.3.  Mapping of the PARAMETERS Clause

   The protocolDirParameters object provides an NMS the ability to turn
   on and off expensive probe resources. An agent may support a given
   parameter all the time, not at all, or subject to current resource
   load.

   The PARAMETERS clause is a list of bit definitions which can be
   directly encoded into the associated ProtocolDirParameters octet in
   network byte order. Zero or more bit definitions may be present. Only
   bits 0-7 are valid encoding values. This clause defines the entire
   BIT set allowed for a given protocol. A conforming agent may choose
   to implement a subset of zero or more of these PARAMETERS.



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


   By convention, the following common bit definitions are used by
   different protocols.  These bit positions must not be used for other
   parameters. They should be reserved if not used by a given protocol.
   Bits are encoded in network-byte order.

         Table 3.1  Reserved PARAMETERS Bits
         ------------------------------------

Bit Name              Description
---------------------------------------------------------------------
0   countsFragments   higher-layer protocols encapsulated within
                      this protocol will be counted correctly even
                      if this protocol fragments the upper layers
                      into multiple packets.
1   tracksSessions    correctly attributes all packets of a protocol
                      which starts sessions on well known ports or
                      sockets and then transfers them to dynamically
                      assigned ports or sockets thereafter (e.g. TFTP).

   The PARAMETERS clause must be present in all protocol-identifier
   macro declarations, but may be equal to zero (empty). Note that an
   NMS must determine if a given PARAMETER bit is supported by
   attempting to create the desired protocolDirEntry The associated
   ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not
   exist.

4.2.3.1.  Mapping of the 'countsFragments(0)' BIT

   This bit indicates whether the probe is correctly attributing all
   fragmented packets of the specified protocol, even if individual
   frames carrying this protocol cannot be identified as such.  Note
   that the probe is not required to actually present any re-assembled
   datagrams (for address-analysis, filtering, or any other purpose) to
   the NMS.

   This bit may only be set in a protocolDirParameters octet which
   corresponds to a protocol that supports fragmentation and reassembly
   in some form. Note that TCP packets are not considered 'fragmented-
   streams' and so TCP is not eligible.

   This bit may be set in at most one protocolDirParameters octet within
   a protocolDirTable INDEX.









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


4.2.3.2.  Mapping of the 'tracksSessions(1)' BIT

   The 'tracksSessions(1)' bit indicates whether frames which are part
   of remapped-sessions (e.g. TFTP download sessions) are correctly
   counted by the probe. For such a protocol, the probe must usually
   analyze all packets received on the indicated interface, and maintain
   some state information, (e.g. the remapped UDP port number for TFTP).

   The semantics of the 'tracksSessions' parameter are independent of
   the other protocolDirParameters definitions, so this parameter may be
   combined with any other legal parameter configurations.

4.2.4.  Mapping of the ATTRIBUTES Clause

   The protocolDirType object provides an NMS with an indication of a
   probe's capabilities for decoding a given protocol, or the general
   attributes of the particular protocol.

   The ATTRIBUTES clause is a list of bit definitions which are encoded
   into the associated instance of ProtocolDirType. The BIT definitions
   are specified in the SYNTAX clause of the protocolDirType MIB object.

         Table 3.2  Reserved ATTRIBUTES Bits
         ------------------------------------

     Bit Name              Description
     ---------------------------------------------------------------------
     0  hasChildren        indicates that there may be children of
                           this protocol defined in the protocolDirTable
                           (by either the agent or the manager).
     1  addressRecognitionCapable
                           indicates that this protocol can be used
                           to generate host and matrix table entries.

   The ATTRIBUTES clause must be present in all protocol-identifier
   macro declarations, but may be empty.

4.2.5.  Mapping of the DESCRIPTION Clause

   The DESCRIPTION clause provides a textual description of the protocol
   identified by this macro.  Notice that it should not contain details
   about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
   REFERENCE clauses.

   The DESCRIPTION clause must be present in all protocol-identifier
   macro declarations.





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


4.2.6.  Mapping of the CHILDREN Clause

   The CHILDREN clause provides a description of child protocols for
   protocols which support them. It has three sub-sections:

  -  Details on the field(s)/value(s) used to select the child protocol,
     and how that selection process is performed

  -  Details on how the value(s) are encoded in the protocol identifier
     octet string

  -  Details on how child protocols are named with respect to their
     parent protocol label(s)

   The CHILDREN clause must be present in all protocol-identifier macro
   declarations in which the 'hasChildren(0)' BIT is set in the
   ATTRIBUTES clause.

4.2.7.  Mapping of the ADDRESS-FORMAT Clause

   The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
   format(s) used when encoding addresses.

   This clause must be present in all protocol-identifier macro
   declarations in which the 'addressRecognitionCapable(1)' BIT is set
   in the ATTRIBUTES clause.

4.2.8.  Mapping of the DECODING Clause

   The DECODING clause provides a description of the decoding procedure
   for the specified protocol. It contains useful decoding hints for the
   implementor, but should not over-replicate information in documents
   cited in the REFERENCE clause.  It might contain a complete
   description of any decoding information required.

   For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
   offset and type information for the field(s) used for child selection
   as well as information on determining the start of the child
   protocol.

   For 'addressRecognitionCapable' protocols this includes offset and
   type information for the field(s) used to generate addresses.

   The DECODING clause is optional, and may be omitted if the REFERENCE
   clause contains pointers to decoding information for the specified
   protocol.





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


4.2.9.  Mapping of the REFERENCE Clause

   If a publicly available reference document exists for this protocol
   it should be listed here.  Typically this will be a URL if possible;
   if not then it will be the name and address of the controlling body.

   The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
   amount of information which may currently be obtained from an
   'authoritative' document, such as the Assigned Numbers document
   [RFC1700]. Any duplication or paraphrasing of information should be
   brief and consistent with the authoritative document.

   The REFERENCE clause is optional, but should be implemented if an
   authoritative reference exists for the protocol (especially for
   standard protocols).

4.2.10.  Evaluating a Protocol-Identifier INDEX

   The following evaluation is done after protocolDirTable INDEX value
   has been converted into two OCTET STRINGs according to the INDEX
   encoding rules specified in the SMI [RFC1902].

   Protocol-identifiers are evaluated left to right, starting with the
   protocolDirID, which length should be evenly divisible by four. The
   protocolDirParameters length should be exactly one quarter of the
   protocolDirID string length.

   Protocol-identifier parsing starts with the base layer identifier,
   which must be present, and continues for one or more upper layer
   identifiers, until all OCTETs of the protocolDirID have been used.
   Layers may not be skipped, so identifiers such as 'SNMP over IP' or
   'TCP over anylink' can not exist.

   The base-layer-identifier also contains a 'special function
   identifier' which may apply to the rest of the protocol identifier.

   Wild-carding at the base layer within a protocol encapsulation is the
   only supported special function at this time. Refer to the 'Base
   Protocol Identifiers' section for wildcard encoding rules.

   After the protocol-tree identified in protocolDirID has been parsed,
   each parameter bit-mask (one octet for each 4-octet layer-identifier)
   is evaluated, and applied to the corresponding protocol layer.

   A protocol-identifier label may map to more than one value.  For
   instance, 'ip' maps to 5 distinct values, one for each supported
   encapsulation.  (see the 'IP' section under 'L3 Protocol
   Identifiers'),



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


   It is important to note that these macros are conceptually expanded
   at implementation time, not at run time.

   If all the macros are expanded completely by substituting all
   possible values of each label for each child protocol, a list of all
   possible protocol-identifiers is produced.  So 'ip' would result in 5
   distinct protocol-identifiers.  Likewise each child of 'ip' would map
   to at least 5 protocol-identifiers, one for each encapsulation (e.g.
   ip over ether2, ip over LLC, etc.).

5.  Protocol Identifier Macros

   The following PROTOCOL IDENTIFIER macros can be used to construct
   protocolDirID and protocolDirParameters strings.

   The sections defining protocol examples are intended to grow over
   subsequent releases. Minimal protocol support is included at this
   time.  (Refer to section 3.2 for details on the protocol macro update
   procedure.)

   An identifier is encoded by constructing the base-identifier, then
   adding one layer-identifier for each encapsulated protocol.

5.1.  Base Identifier Encoding

   The first layer encapsulation is called the base identifier and it
   contains optional protocol-function information and the base layer
   (e.g.  MAC layer) enumeration value used in this protocol identifier.

   The base identifier is encoded as four octets as shown in figure 2.

          Fig. 2
     base-identifier format
     +---+---+---+---+
     |   |   |   |   |
     | f |op1|op2| m |
     |   |   |   |   |
     +---+---+---+---+ octet
     | 1 | 1 | 1 | 1 | count

   The first octet ('f') is the special function code, found in table
   4.1.  The next two octets ('op1' and 'op2') are operands for the
   indicated function. If not used, an operand must be set to zero.  The
   last octet, 'm', is the enumerated value for a particular base layer
   encapsulation, found in table 4.2.  All four octets are encoded in
   network-byte-order.





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


5.1.1.  Protocol Identifier Functions

   The base layer identifier contains information about any special
   functions to perform during collections of this protocol, as well as
   the base layer encapsulation identifier.

   The first three octets of the identifier contain the function code
   and two optional operands. The fourth octet contains the particular
   base layer encapsulation used in this protocol (fig. 2).

     Table 4.1  Assigned Protocol Identifier Functions
     -------------------------------------------------

           Function     ID    Param1               Param2
           ----------------------------------------------------
           none          0    not used (0)         not used (0)
           wildcard      1    not used (0)         not used (0)

5.1.1.1.  Function 0: No-op

   If the function ID field (1st octet) is equal to zero, the the 'op1'
   and 'op2' fields (2nd and 3rd octets) must also be equal to zero.
   This special value indicates that no functions are applied to the
   protocol identifier encoded in the remaining octets. The identifier
   represents a normal protocol encapsulation.

5.1.1.2.  Function 1: Protocol Wildcard Function

   The wildcard function (function-ID = 1), is used to aggregate
   counters, by using a single protocol value to indicate potentially
   many base layer encapsulations of a particular network layer
   protocol. A protocolDirEntry of this type will match any base-layer
   encapsulation of the same protocol.

   The 'op1' field (2nd octet) is not used and must be set to zero.

   The 'op2' field (3rd octet) is not used and must be set to zero.

   Each wildcard protocol identifier must be defined in terms of a 'base
   encapsulation'. This should be as 'standard' as possible for
   interoperability purposes. If an encapsulation over 'ether2' is
   permitted, than this should be used as the base encapsulation.