rfc2895.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,673 行 · 第 1/5 页

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


   This document does not discuss auto-discovery and auto-population of
   the protocolDirTable. This functionality is not explicitly defined by
   the RMON standard. An agent SHOULD populate the directory with the
   'interesting' protocols on which the intended applications depend.

2.3.  Relationship to the RMON Protocol Identifier Macros Document

   The original RMON Protocol Identifiers document [RFC2074] contains
   the protocol directory reference material, as well as many examples
   of protocol identifier macros.

   These macros have been moved to a separate document called the RMON
   Protocol Identifier Macros document [RFC2896].  This will allow the
   normative text (this document) to advance on the standards track with
   the RMON-2 MIB [RFC2021], while the collection of PI macros is
   maintained in an Informational RFC.

   The PI Macros document is intentionally separated from this document
   to allow updates to the list of published PI macros without any
   republication of MIB objects or encoding rules.  Protocol Identifier
   macros submitted from the RMON working group and community at large
   (to the RMONMIB WG mailing list at '[e-mail]') will be
   collected, screened by the RMONMIB working group, and (if approved)
   added to a subsequent version of the PI Macros document.

   Macros submissions will be collected in the IANA's MIB files under
   the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in
   the RMONMIB working group mailing list message archive file
   www.ietf.org/mail-archive/working-
   groups/rmonmib/current/maillist.htm.

2.4.  Relationship to the ATM-RMON MIB

   The ATM Forum has standardized "Remote Monitoring MIB Extensions for
   ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides
   RMON-like stats, host, matrix, and matrixTopN capability for NSAP
   address-based (ATM Adaption Layer 5, AAL-5) cell traffic.

2.4.1.  Port Aggregation

   It it possible to correlate ATM-RMON MIB data with packet-based
   RMON-2 [RFC2021] collections, but only if the ATM-RMON
   'portSelGrpTable' and 'portSelTable' are configured to provide the
   same level of port aggregation as used in the packet-based
   collection.  This will require an ATM-RMON 'portSelectGroup' to
   contain a single port, in the case of traditional RMON dataSources.





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


2.4.2.  Encapsulation Mappings

   The RMON PI document does not contain explicit PI macro support for
   "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483],
   or ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000].
   Instead, a probe must 'fit' the ATM encapsulation to one of the base
   layers defined in this document (i.e., llc, snap, or vsnap),
   regardless of how the raw data is obtained by the agent (e.g., VC-
   muxing vs. LLC-muxing, or routed vs. bridged formats).  See section
   3.2 for details on identifying and decoding a particular base layer.

   An NMS can determine some of the omitted encapsulation details by
   examining the interface type (ifType) of the dataSource for a
   particular RMON collection:

      RFC 1483 dataSource ifTypes:
           - aal5(49)

      LANE dataSource ifTypes:
           - aflane8023(59)
           - aflane8025(60)

   These dataSources require implementation of the ifStackTable from the
   Interfaces MIB [RFC2233].  It is possible that some implementations
   will use dataSource values which indicate an ifType of 'atm(37)'
   (because the ifStackTable is not supported), however this is strongly
   discouraged by the RMONMIB WG.

2.4.3.  Counting ATM Traffic in RMON-2 Collections

   The RMON-2 Application Layer (AL) and Network Layer (NL)
   (host/matrix/topN) tables require that octet counters be incremented
   by the size of the particular frame, not by the size of the frame
   attributed to a given protocol.

   Probe implementations must use the AAL-5 frame size (not the AAL-5
   payload size or encapsulated MAC frame size) as the 'frame size' for
   the purpose of incrementing RMON-2 octet counters (e.g.,
   'nlHostInOctets', 'alHostOutOctets').

   The RMONMIB WG has not addressed issues relating to packet capture of
   AAL-5 based traffic. Therefore, it is an implementation-specific
   matter whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3
   or 802.5 traffic, or LANE traffic) are represented in the RMON-1
   'captureBufferPacketData' MIB object.   Normally, the first octet of
   the captured frame is the first octet of the destination MAC address
   (DA).




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


2.5.  Relationship to Other MIBs

   The RMON Protocol Identifiers Reference document is intended for use
   with the protocolDirTable within the RMON MIB. It is not relevant to
   any other MIB, or intended for use with any other MIB.

3.  Protocol Identifier Encoding

   The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID
   and protocolDirParameters. To encode the table index, each variable-
   length string is converted to an OBJECT IDENTIFIER fragment,
   according to the encoding rules in section 7.7 of RFC 1902 [RFC1902].
   Then the index fragments are simply concatenated.  (Refer to figures
   1a - 1d below for more detail.)

   The first OCTET STRING (protocolDirID) is composed of one or more 4-
   octet "layer-identifiers". The entire string uniquely identifies a
   particular node in the protocol encapsulation tree. The second OCTET
   STRING, (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, then it must be
   defined as an '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, et al.             Standards Track                     [Page 9]

RFC 2895                   RMON PI Reference                 August 2000


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

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

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

   N is the number of protocol-layer-identifiers required
   for the entire encapsulation of the named protocol.  Note
   that the layer following the base layer usually identifies
   a network layer protocol, but this is not always the case,
   (most notably for children of the 'vsnap' base-layer).

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

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

   When encoded in a protocolDirTable INDEX, each of the two
   strings must be preceded by a length sub-component. In this
   example, N equals '4', the first 'cnt' field would contain
   the value '16', and the second 'cnt' field would contain
   the value '4'.










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


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

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


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


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

3.1.  ProtocolDirTable INDEX Format Examples

   The following PI identifier fragments are examples of some fully
   encoded protocolDirTable INDEX values for various encapsulations.

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

    -- 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.snmp =
       12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0




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


    -- IPX over LLC
    llc.ipx =
       8.0.0.0.2.0.0.0.224.2.0.0

    -- SNMP over UDP/IP over any link layer
    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
    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-oui.atalk
      12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0

3.2.  Protocol Identifier Macro Format

   The following example is meant to introduce the protocol-identifier
   macro. This macro-like construct 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.  This
   clause is currently used only for IANA assigned protocols, enumerated
   under the 'ianaAssigned' base-layer.  The VariantOfPart component
   MUST be present for IANA assigned protocols.

3.2.1.  Lexical Conventions

   The PI language defines the following keywords:

         ADDRESS-FORMAT
         ATTRIBUTES
         CHILDREN
         DECODING
         DESCRIPTION
         PARAMETERS
         PROTOCOL-IDENTIFIER
         REFERENCE
         VARIANT-OF