rfc2895.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

3.2.9.  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.









Bierman, et al.             Standards Track                    [Page 19]

RFC 2895                   RMON PI Reference                 August 2000


3.2.10.  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.

3.2.11.  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.

3.2.12.  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).







Bierman, et al.             Standards Track                    [Page 20]

RFC 2895                   RMON PI Reference                 August 2000


3.3.  Evaluating an Index of the ProtocolDirTable

   The following evaluation is done after a 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 MUST be evenly divisible by four. The
   protocolDirParameters length MUST 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 MUST NOT be skipped, so identifiers such as 'SNMP over IP' or
   'TCP over ether2' 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. (See section 4.1.1.2
   for details.)

   After the protocol-identifier string (which is the value of
   protocolDirID) has been parsed, each octet of the protocol-parameters
   string 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'
   in the RMON Protocol Identifier Macros document [RFC2896]).

   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.).









Bierman, et al.             Standards Track                    [Page 21]

RFC 2895                   RMON PI Reference                 August 2000


4.  Base Layer Protocol Identifier Macros

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

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

   Refer to the RMON Protocol Identifier Macros document [RFC2896] for a
   listing of the non-base layer PI macros published by the working
   group. Note that other PI macro documents may exist, and it should be
   possible for an implementor to populate the protocolDirTable without
   the use of the PI Macro document [RFC2896].

4.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.

4.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).




Bierman, et al.             Standards Track                    [Page 22]

RFC 2895                   RMON PI Reference                 August 2000


      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)

4.1.1.1.  Function 0: None

   If the function ID field (1st octet) is equal to zero, 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.

4.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 network layer 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.  The lowest possible base layer value
   SHOULD be chosen.  So, if an encapsulation over 'ether2' is
   permitted, than this should be used as the base encapsulation. If not
   then an encapsulation over LLC should be used, if permitted.  And so
   on for each of the defined base layers.

   It should be noted that an agent does not have to support the non-
   wildcard protocol identifier over the same base layer.  For instance
   a token ring only device would not normally support IP over the
   ether2 base layer.  Nevertheless it should use the ether2 base layer
   for defining the wildcard IP encapsulation.  The agent MAY also
   support counting some or all of the individual encapsulations for the
   same protocols, in addition to wildcard counting.  Note that the
   RMON-2 MIB [RFC2021] does not require that agents maintain counters
   for multiple encapsulations of the same protocol.  It is an
   implementation-specific matter as to how an agent determines which
   protocol combinations to allow in the protocolDirTable at any given
   time.



Bierman, et al.             Standards Track                    [Page 23]

RFC 2895                   RMON PI Reference                 August 2000


4.2.  Base Layer Protocol Identifiers

   The base layer is mandatory, and defines the base encapsulation of
   the packet and any special functions for this identifier.

   There are no suggested protocolDirParameters bits for the base layer.

   The suggested value for the ProtocolDirDescr field for the base layer
   is given by the corresponding "Name" field in the table 4.2 below.
   However, implementations are only required to use the appropriate
   integer identifier values.

   For most base layer protocols, the protocolDirType field should
   contain bits set for  the 'hasChildren(0)' and '
   addressRecognitionCapable(1)' attributes.  However, the special
   'ianaAssigned' base layer should have no parameter or attribute bits
   set.

   By design, only 255 different base layer encapsulations are
   supported.  There are five base encapsulation values defined at this
   time. Very few new base encapsulations (e.g. for new media types) are
   expected to be added over time.

     Table 4.2  Base Layer Encoding Values
     --------------------------------------

           Name          ID
           ------------------
           ether2        1
           llc           2
           snap          3
           vsnap         4
           ianaAssigned  5

 -- Ether2 Encapsulation

ether2 PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0),
        addressRecognitionCapable(1)
    }
    DESCRIPTION
       "DIX Ethernet, also called Ethernet-II."
    CHILDREN
       "The Ethernet-II type field is used to select child protocols.
       This is a 16-bit field.  Child protocols are deemed to start at
       the first octet after this type field.



Bierman, et al.             Standards Track                    [Page 24]

RFC 2895                   RMON PI Reference                 August 2000


       Children of this protocol are encoded as [ 0.0.0.1 ], the
       protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
       'a' and 'b' are the network byte order encodings of the high
       order byte and low order byte of the Ethernet-II type value.

       For example, a protocolDirID-fragment value of:
          0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.

       Children of ether2 are named as 'ether2' followed by the type
       field value in hexadecimal.  The above example would be declared
       as:
          ether2 0x0800"
    ADDRESS-FORMAT
       "Ethernet addresses are 6 octets in network order."
    DECODING
       "Only type values greater than 1500 decimal indicate Ethernet-II
       frames; lower values indicate 802.3 encapsulation (see below)."
    REFERENCE
       "The authoritative list of Ether Type values is identified by the
       URL:

          ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
    ::= { 1 }

 -- LLC Encapsulation

llc PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0),