rfc2895.txt

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

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


   The PI language defines the following punctuation elements:

        {     left curly brace
        }     right curly brace
        (     left parenthesis
        )     right parenthesis
        ,     comma
        ::=   two colons and an equal sign
        --    two dashes

3.2.2.  Notation for Syntax Descriptions

   An extended form of the BNF notation is used to specify the syntax of
   the PI language. The rules for this notation are shown below:

     *  Literal values are specified in quotes, for example "REFERENCE"

     *  Non-terminal items are surrounded by less than (<) and greater
        than (>) characters, for example <parmList>

     *  Terminal items are specified without surrounding quotes or less
        than and greater than characters, for example 'lcname'

     *  A vertical bar (|) is used to indicate a choice between items,
        for example 'number | hstr'

     *  Ellipsis are used to indicate that the previous item may be
        repeated one or more times, for example <parm>...

     *  Square brackets are used to enclose optional items, for example
        [ "," <parm> ]

     *  An equals character (=) is used to mean "defined as," for
        example '<protoName> = pname'

3.2.3.  Grammar for the PI Language

   The following are "terminals" of the grammar and are identical to the
   same lexical elements from the MIB module language, except for hstr
   and pname:

       <lc>     = "a" | "b" | "c" | ... | "z"
       <uc>     = "A" | "B" | "C" | ... | "Z"
       <letter> = <lc> | <uc>
       <digit>  = "0" | "1" | ... | "9"
       <hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"





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


       <lcname> = <lc> [ <lcrest> ]
       <lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]

       <pname>  = ( <letter> | <digit> ) [ <pnrest> ]
       <pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]

       <number> = <digit> [ <number> ]  -- to a max dec. value of 4g-1

       <hstr>   = "0x" <hrest>          -- to a max dec. value of 4g-1
       <hrest>  = <hdigit> [ <hrest> ]

       <lf>     = linefeed char
       <cr>     = carriage return char
       <eoln>   = <cr><lf> | <lf>

       <sp>     = " "
       <tab>    = "    "
       <wspace> = { <sp> | <tab> | <eoln> } [<wspace>]

       <string> = """ [ <strest> ] """
       <strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]

   The following is the extended BNF notation for the grammar with
   starting symbol <piFile>:

       -- a file containing one or more Protocol Identifier (PI)
       -- definitions
       <piFile> = <piDefinition>...

       -- a PI definition
       <piDefinition> =
         <protoName> "PROTOCOL-IDENTIFIER"
             [ "VARIANT-OF" <protoName> ]
               "PARAMETERS" "{" [ <parmList> ] "}"
               "ATTRIBUTES" "{" [ <attrList> ] "}"
               "DESCRIPTION" string
             [ "CHILDREN" string ]
             [ "ADDRESS-FORMAT" string ]
             [ "DECODING" string ]
             [ "REFERENCE" string ]
               "::=" "{" <encapList> "}"

       -- a protocol name
       <protoName> = pname

       -- a list of parameters
       <parmList> = <parm> [ "," <parm> ]...




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


       -- a parameter
       <parm> = lcname [<wspace>] "(" [<wspace>]
                 <nonNegNum> [<wspace>] ")" [<wspace>]

       -- list of attributes
       <attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...

       -- an attribute
       <attr> = lcname [<wspace>] "(" [<wspace>]
                 <nonNegNum> [<wspace>] ")"

       -- a non-negative number
       <nonNegNum> = number | hstr

       -- list of encapsulation values
       <encapList> = <encapValue> [ [<wspace>] ","
                       [<wspace>] <encapValue> ]...

       -- an encapsulation value
       <encapValue> = <baseEncapValue> | <normalEncapValue>

       -- base encapsulation value
       <baseEncapValue> = <nonNegNum>

       -- normal encapsulation value
        <normalEncapValue> = <protoName> <wspace> <nonNegNum>

       -- comment
       <two dashes> <text> <end-of-line>

3.2.4.  Mapping of the Protocol Name

   The "protoName" value, called the "protocol name" shall be an ASCII
   string consisting of one up to 64 characters from the following:

        "A" through "Z"
        "a" through "z"
        "0" through "9"
        dash (-)
        underbar (_)
        asterisk (*)
        plus(+)

   The first character of the protocol name is limited to one of the
   following:

        "A" through "Z"
        "a" through "z"



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


        "0" through "9"

   This value SHOULD be the name or acronym identifying the protocol.
   Note that case is significant.  The value selected for the 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.  Likewise, children of
   UDP and TCP SHOULD be given names consistent with the port number
   name assignments found in:

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

   When the "well-known name" contains characters not allowed in
   protocol names, they MUST be changed to a dash character ("-") . In
   the event that the first character must be changed, the protocol name
   is prepended with the letter "p", so the former first letter may be
   changed to a dash.

   For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g.  The
   following protocol names are legal:

       ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu

   Note that it is possible in actual implementation that different
   encapsulations of the same protocol (which are represented by
   different entries in the protocolDirTable) will be assigned the same
   protocol name.  The protocolDirID INDEX value defines a particular
   protocol, not the protocol name string.

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




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


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

   Note that if an '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.

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

   By convention, the following common bit definitions are used by
   different protocols.  These bit positions MUST NOT be used for other
   parameters. They MUST be reserved if not used by a given protocol.

   Bits are encoded in a single octet. Bit 0 is the high order (left-
   most) bit in the octet, and bit 7 is the low order (right-most) bit
   in the first octet. Reserved bits and unspecified bits in the octet
   are set to zero.

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




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


   The PARAMETERS clause MUST be present in all protocol-identifier
   macro declarations, but may be equal to zero (empty).

3.2.6.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 MUST 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 more than one protocolDirParameters octet
   within a protocolDirTable INDEX, in the event an agent can count
   fragments at more than one protocol layer.

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

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