rfc2895.txt

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

     addressRecognitionCapable(1)
    }
    DESCRIPTION
       "The Logical Link Control (LLC) 802.2 protocol."
    CHILDREN
       "The LLC Source Service Access Point (SSAP) and Destination
       Service Access Point (DSAP) 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).





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


       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 raw 802.3
       encapsulations).  For 802.5 there is no other link layer
       protocol.

       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 }

 -- SNAP over LLC (Organizationally Unique Identifier, OUI=000)
 -- Encapsulation

snap PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {



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


     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 Protocol Identifier field (PID) 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 high order byte and low order byte 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"
    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 Organizationally Unique Identifier (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 }



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


 -- Vendor 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 have a
       zero OUI value."
    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 ] where
       'a', 'b' and 'c' are the 3 octets of the OUI field in network
       byte order.

       For example, a protocolDirID-fragment value of:
         0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
       over vsnap.

       Children are named as 'vsnap <OUI>', where the '<OUI>' field is
       represented as 3 octets in hexadecimal notation.

       So the above example would be named:
         'vsnap 0x080007'"
    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 and the SNAP
       Protocol Identifier is not parsed."
    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 }




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


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

       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 'limited extensibility' feature of the
       protocolDirTable, and do not need special IANA assignments.

       A centrally located list of these enumerated protocols must be
       maintained by IANA to insure interoperability. (See section 2.3
       for details on the document update procedure.)  Support for new
       link-layers will be added explicitly, and only protocols which
       cannot possibly be represented in a better way will be considered
       as 'ianaAssigned' protocols.

       IANA protocols are identified by the base-layer-selector value [
       0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer
       value corresponding to the particular IANA protocol.

       Do not create children of this protocol unless you are sure that
       they cannot be handled by the more conventional link layers
       above."
    CHILDREN
       "Children of this protocol are identified by implementation-
       specific means, described (as best as possible) in the 'DECODING'
       clause within the protocol-variant-identifier macro for each
       enumerated protocol.

       Children of this protocol are encoded as [ 0.0.0.5 ], the
       protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ]
       where 'a', 'b' are the network byte order encodings of the high
       order byte and low order byte of the enumeration value for the
       particular IANA assigned protocol.






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


       For example, a protocolDirID-fragment value of:
          0.0.0.5.0.0.0.1

       defines the IPX protocol encapsulated directly in 802.3

       Children are named 'ianaAssigned' followed by the numeric value
       of the particular IANA assigned protocol.  The above example
       would be named:

          'ianaAssigned 1' "
    DECODING
       "The 'ianaAssigned' base layer is a pseudo-protocol and is not
       decoded."
    REFERENCE
       "Refer to individual PROTOCOL-IDENTIFIER macros for information
       on each child of the IANA assigned protocol."
    ::= { 5 }

 -- The following protocol-variant-identifier macro declarations are
 -- used to identify the RMONMIB IANA assigned protocols in a
 -- proprietary way, by simple enumeration.

ipxOverRaw8023 PROTOCOL-IDENTIFIER
    VARIANT-OF  ipx
    PARAMETERS      { }
    ATTRIBUTES  { }
    DESCRIPTION
       "This pseudo-protocol describes an encapsulation of IPX over
       802.3, without a type field.

       Refer to the macro for IPX for additional information about this
       protocol."
    DECODING
       "Whenever the 802.3 header indicates LLC a set of protocol
       specific tests needs to be applied to determine whether this is a
       'raw8023' packet or a true 802.2 packet.  The nature of these
       tests depends on the active child protocols for 'raw8023' and is
       beyond the scope of this document."
    ::= {
     ianaAssigned 1,             -- [0.0.0.1]
     802-1Q       0x05000001     -- 1Q_IANA [5.0.0.1]
    }









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


4.3.  Encapsulation Layers

   Encapsulation layers are positioned between the base layer and the
   network layer.  It is an implementation-specific matter whether a
   probe exposes all such encapsulations in its RMON-2 Protocol
   Directory.

4.3.1.  IEEE 802.1Q

   RMON probes may encounter 'VLAN tagged' frames on monitored links.
   The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and
   [IEEE802.1D-1998], define an encapsulation layer inserted after the
   MAC layer and before the network layer.  This section defines a PI
   macro which supports most (but not all) features of that
   encapsulation layer.

   Most notably, the RMON PI macro '802-1Q' does not expose the Token
   Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN
   header.  It is an implementation specific matter whether an RMON
   probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native
   (LLC-N) format, for the purpose of RMON collection.

   In order to support the Ethernet and LLC-N formats in the most
   efficient manner, and still maintain alignment with the RMON-2 '
   collapsed' base layer approach (i.e., support for snap and vsnap),
   the children of 802dot1Q are encoded a little differently than the
   children of other base layer identifiers.

802-1Q   PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0)
    }
    DESCRIPTION
       "IEEE 802.1Q VLAN Encapsulation header.

       Note that the specific encoding of the TPID field is not