rfc2074.txt

RFC 的详细文档！

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


   The agent may also be requested to count some or all of the
   individual encapsulations for the same protocols, in addition to
   wildcard counting.  Note that the RMON-2 MIB [RMON2] 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.

5.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 ProtocolDirDescr field for the base layer is given by
   the corresponding "Name" field in the table 4.1 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. 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










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


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

       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 MSB and
       LSB 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 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 or equal to 1500 decimal indicate
       Ethernet-II frames; lower values indicate 802.3 encapsulation
       (see below)."
    REFERENCE
       "A Standard for the Transmission of IP Datagrams over Ethernet
       Networks; RFC 894 [RFC894].

       The authoritative list of Ether Type values is identified by the
       URL:

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










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


5.2.2.  LLC Encapsulation

llc PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
        hasChildren(0),
        addressRecognitionCapable(1)
    }
    DESCRIPTION
       "The LLC (802.2) protocol."
    CHILDREN
       "The LLC SSAP and DSAP (Source/Dest Service Access Points) are
       used to select child protocols.  Each of these is one octet long,
       although the least significant bit is a control bit and should be
       masked out in most situations.  Typically SSAP and DSAP (once
       masked) are the same for a given protocol - each end implicitly
       knows whether it is the server or client in a client/server
       protocol.  This is only a convention, however, and it is possible
       for them to be different.  The SSAP is matched against child
       protocols first.  If none is found then the DSAP is matched
       instead.  The child protocol is deemed to start at the first
       octet after the LLC control field(s).

       Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
       identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
       the SAP value which maps to the child protocol.  For example, a
       protocolDirID-fragment value of:
          0.0.0.2.0.0.0.240

       defines NetBios over LLC.

       Children are named as 'llc' followed by the SAP value in
       hexadecimal.  So the above example would have been named:
          llc 0xf0"
    ADDRESS-FORMAT
       "The address consists of 6 octets of MAC address in network
       order.  Source routing bits should be stripped out of the address
       if present."
    DECODING
       "Notice that LLC has a variable length protocol header; there are
       always three octets (DSAP, SSAP, control).  Depending on the
       value of the control bits in the DSAP, SSAP and control fields
       there may be an additional octet of control information.

       LLC can be present on several different media.  For 802.3 and
       802.5 its presence is mandated (but see ether2 and raw802.3
       encapsulations).  For 802.5 there is no other link layer
       protocol.



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


       Notice also that the raw802.3 link layer protocol may take
       precedence over this one in a protocol specific manner such that
       it may not be possible to utilize all LSAP values if raw802.3 is
       also present."
    REFERENCE
       "The authoritative list of LLC LSAP values is controlled by the
       IEEE Registration Authority:
       IEEE Registration Authority
          c/o Iris Ringel
          IEEE Standards Dept
          445 Hoes Lane, P.O. Box 1331
          Piscataway, NJ 08855-1331
          Phone [phone]
          Fax: [phone]"
    ::= { 2 }

5.2.3.  SNAP over LLC (OUI=000) Encapsulation

snap PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
        hasChildren(0),
        addressRecognitionCapable(1)
    }
    DESCRIPTION
       "The Sub-Network Access Protocol (SNAP) is layered on top of LLC
       protocol, allowing Ethernet-II protocols to be run over a media
       restricted to LLC."
    CHILDREN
       "Children of 'snap' are identified by Ethernet-II type values;
       the SNAP PID (Protocol Identifier) field is used to select the
       appropriate child.  The entire SNAP protocol header is consumed;
       the child protocol is assumed to start at the next octet after
       the PID.

       Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
       identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
       are the MSB and LSB of the Ethernet-II type value.  For example,
       a protocolDirID-fragment value of:
          0.0.0.3.0.0.8.0

       defines the IP/SNAP protocol.

       Children of this protocol are named 'snap' followed by the
       Ethernet-II type value in hexadecimal.  The above example would
       be named:

          snap 0x0800"



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


    ADDRESS-FORMAT
         "The address format for SNAP is the same as that for LLC"
    DECODING
       "SNAP is only present over LLC.  Both SSAP and DSAP will be 0xAA
       and a single control octet will be present.  There are then three
       octets of OUI and two octets of PID.  For this encapsulation the
       OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
    REFERENCE
       "SNAP Identifier values are assigned by the IEEE Standards
       Office.  The address is:
               IEEE Registration Authority
               c/o Iris Ringel
               IEEE Standards Dept
               445 Hoes Lane, P.O. Box 1331
               Piscataway, NJ 08855-1331
               Phone [phone]
               Fax: [phone]"
    ::= { 3 }

5.2.4.  SNAP over LLC (OUI != 000) Encapsulation

vsnap PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
        hasChildren(0),
        addressRecognitionCapable(1)
    }
    DESCRIPTION
       "This pseudo-protocol handles all SNAP packets which do not have
       a zero OUI.  See 'snap' above for details of those that do."
    CHILDREN
       "Children of 'vsnap' are selected by the 3 octet OUI; the PID is
       not parsed; child protocols are deemed to start with the first
       octet of the SNAP PID field, and continue to the end of the
       packet.

       Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
       identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
       'a', 'b' and 'c' are the 3 octets of the OUI field in network
       byte order. This is in turn followed by the 16-bit EtherType
       value, where the 'd' and 'e' represent the MSB and LSB of the
       EtherType, respectively.

       For example, a protocolDirID-fragment value of:
         0.0.0.4.0.8.0.7.0.0.128.155
       defines the AppleTalk Phase 2 protocol over vsnap.





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


       Note that two protocolDirParameters octets must be present in
       protocolDirTable INDEX values for 'vsnap' protocols.  The first
       protocolDirParameters octet defines the actual parameters. The
       second protocolDirParameters octet is not used and must be set to
       zero.

       Children are named as 'vsnap(<OUI>) <ethertype>', where the
       '<OUI>' field is represented as 3 octets in hexadecimal notation
       or the ASCII string associated with the OUI value. The
       <ethertype> field is represented by the 2 byte EtherType value in
       hexadecimal notation. So the above example would be named:

         'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
    ADDRESS-FORMAT
       "The LLC address format is inherited by 'vsnap'.  See the 'llc'
       protocol identifier for more details."
    DECODING
       "Same as for 'snap' except the OUI is non-zero."
    REFERENCE
       "SNAP Identifier values are assigned by the IEEE Standards
       Office.  The address is:
               IEEE Registration Authority
               c/o Iris Ringel
               IEEE Standards Dept
               445 Hoes Lane, P.O. Box 1331
               Piscataway, NJ 08855-1331
               Phone [phone]
               Fax: [phone]"
    ::= { 4 }

5.2.5.  IANA Assigned Protocols

ianaAssigned PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "This branch contains protocols which do not conform easily to
       the hierarchical format utilized in the other link layer
       branches.  Usually, such a protocol 'almost' conforms to a
       particular 'well-known' identifier format, but additional
       criteria are used (e.g. configuration-based), making protocol
       identification difficult or impossible by examination of
       appropriate network traffic.  preventing the any 'well-known'
       protocol-identifier macro from being used.







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


       Sometimes well-known protocols are simply remapped to a different
       port number by one or more venders (e.g. SNMP). These protocols
       can be identified with the 'user-extensibility' feature of the
       protocolDirTable, and do not need special IANA
       assignments.

       A centrally located list of these enumerated protocols must be
       maintained to insure interoperability.
       (See section 3.2 for details on the document update procedure.)
       Support for new link-layers will be added explicitly, and only