rfc2896.txt

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

Network Working Group                                         A. Bierman
Requests for Comment: 2896                                      C. Bucci
Category: Informational                              Cisco Systems, Inc.
                                                                R. Iddon
                                                              3Com, Inc.
                                                             August 2000


        Remote Network Monitoring MIB Protocol Identifier Macros

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo contains various protocol identifier examples, which can be
   used to produce valid protocolDirTable INDEX encodings, as defined by
   the Remote Network Monitoring MIB (Management Information Base)
   Version 2 [RFC2021] and the RMON Protocol Identifier Reference
   [RFC2895].

   This document contains protocol identifier macros for well-known
   protocols.  A conformant implementation of the RMON-2 MIB [RFC2021]
   can be accomplished without the use of these protocol identifiers,
   and accordingly, this document does not specify any IETF standard.
   It is published to encourage better interoperability between RMON-2
   agent implementations, by providing a great deal of RMON related
   protocol information in one document.

   The first version of the RMON Protocol Identifiers Document [RFC2074]
   has been split into a standards-track Reference portion [RFC2895],
   and an "RMON Protocol Identifier Macros", document (this document)
   which contains the non-normative portion of that specification.

Table of Contents

   1 The SNMP Network Management Framework .........................  2
   2 Overview ......................................................  3
   2.1 Terms .......................................................  3
   2.2 Relationship to the Remote Network Monitoring MIB ...........  4
   2.3 Relationship to the RMON Protocol Identifier Reference ......  4



Bierman, et al.              Informational                      [Page 1]

RFC 2896                     RMON PI Macros                  August 2000


   2.4 Relationship to Other MIBs ..................................  4
   3 Protocol Identifier Macros ....................................  4
   3.1 Protocol Stacks And Single-Vendor Applications ..............  5
   3.1.1 The TCP/IP protocol stack .................................  5
   3.1.2 Novell IPX Stack .......................................... 44
   3.1.3 The XEROX Protocol Stack .................................. 49
   3.1.4 AppleTalk Protocol Stack .................................. 51
   3.1.5 Banyon Vines Protocol Stack ............................... 56
   3.1.6 The DECNet Protocol Stack ................................. 61
   3.1.7 The IBM SNA Protocol Stack.  .............................. 65
   3.1.8 The NetBEUI/NetBIOS Family ................................ 66
   3.2 Multi-stack protocols ....................................... 70
   4 Intellectual Property ......................................... 72
   5 Acknowledgements .............................................. 72
   6 References .................................................... 73
   7 Security Considerations ....................................... 82
   8 Authors' Addresses ............................................ 83
   9 Full Copyright Statement ...................................... 84

1.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

    o   An overall architecture, described in RFC 2571 [RFC2571].

    o   Mechanisms for describing and naming objects and events for the
        purpose of management. The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
        1215 [RFC1215].  The second version, called SMIv2, is described
        in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
        STD 58, RFC 2580 [RFC2580].

    o   Message protocols for transferring management information. The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [RFC1157]. A second version of the
        SNMP message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
        and RFC 1906 [RFC1906]. The third version of the message
        protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
        RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

    o   Protocol operations for accessing management information. The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [RFC1157]. A second set o
        protocol operations and associated PDU formats is described in
        RFC 1905 [RFC1905].



Bierman, et al.              Informational                      [Page 2]

RFC 2896                     RMON PI Macros                  August 2000


    o   A set of fundamental applications described in RFC 2573
        [RFC2573] and the view-based access control mechanism described
        in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo does not specify a MIB module.

2.  Overview

   The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs
   to globally identify individual protocol encapsulations in the
   protocolDirTable.

   This guide contains examples of protocol identifier encapsulations,
   which can be used to describe valid protocolDirTable entries.  The
   syntax of the protocol identifier descriptor is defined in the RMON
   Protocol Identifier Reference [RFC2895].

   This document is not intended to be an authoritative reference on the
   protocols described herein. Refer to the Official Internet Standards
   document [RFC2600], the Assigned Numbers document [RFC1700], or other
   appropriate RFCs, IEEE documents, etc. for complete and authoritative
   protocol information.

   This is the the second revision of this document, and is intended to
   replace Section 5 of the first RMON-2 Protocol Identifiers document
   [RFC2074].

   The RMONMIB working group has decided to discontinue maintenance of
   this Protocol Identifier Macro repository document, due to a lack of
   contributions from the RMON vendor community. This document is
   published as an aid in implementation of the protocolDirTable.

2.1.  Terms

   Refer to the RMON Protocol Identifier Reference [RFC2895] for
   definitions of terms used to describe the Protocol Identifier Macro
   and aspects of protocolDirTable INDEX encoding.







Bierman, et al.              Informational                      [Page 3]

RFC 2896                     RMON PI Macros                  August 2000


2.2.  Relationship to the Remote Network Monitoring MIB

   This document is intended to describe some protocol identifier
   macros, which can be converted to valid protocolDirTable INDEX
   values, using the mapping rules defined in the RMON Protocol
   Identifier Reference [RFC2895].

   This document is not intended to limit the protocols that may be
   identified for counting in the RMON-2 MIB. Many protocol
   encapsulations, not explicitly identified in this document, may be
   present in an actual implementation of the protocolDirTable. Also,
   implementations of the protocolDirTable may not include all the
   protocols identified in the example section below.

2.3.  Relationship to the RMON Protocol Identifier Reference

   This document is intentionally separated from the normative reference
   document defining protocolDirTable INDEX encoding rules and the
   protocol identifier macro syntax [RFC2895].  This allows frequent
   updates to this document without any republication of MIB objects or
   protocolDirTable INDEX encoding rules.  Note that the base layer and
   IANA assigned protocol identifier macros are located in Reference
   document, since these encoding values are defined by the RMONMIB WG.

   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 and added to this 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
   "ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib".

2.4.  Relationship to Other MIBs

   The RMON Protocol Identifier Macros document is intended for use with
   the RMON Protocol Identifier Reference [RFC2895] and the RMON-2 MIB
   protocolDirTable [RFC2021]. It is not relevant to any other MIB, or
   intended for use with any other MIB.

3.  Protocol Identifier Macros

   This section contains protocol identifier macros for some well-known
   protocols, although some of them may no longer be in use.  These
   macros reference the base layer identifiers found in section 4 of the
   RMON Protocol Identifier Reference [RFC2895].  These identifiers are
   listed below:




Bierman, et al.              Informational                      [Page 4]

RFC 2896                     RMON PI Macros                  August 2000


         ether2
         llc
         snap
         vsnap
         ianaAssigned
         802-1Q

   Refer to the RMON Protocol Identifier Reference [RFC2895] for the
   protocol identifier macro definitions for these protocols.

3.1.  Protocol Stacks And Single-Vendor Applications

   Network layer protocol identifier macros contain additional
   information about the network layer, and is found immediately
   following a base layer-identifier in a protocol identifier.

   The ProtocolDirParameters supported at the network layer are '
   countsFragments(0)', and 'tracksSessions(1).  An agent may choose to
   implement a subset of these parameters.

   The protocol-name should be used for the ProtocolDirDescr field.  The
   ProtocolDirType ATTRIBUTES used at the network layer are '
   hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose
   to implement a subset of these attributes for each protocol, and
   therefore limit which tables the indicated protocol can be present
   (e.g. protocol distribution, host, and matrix tables).

   The following protocol-identifier macro declarations are given for
   example purposes only. They are not intended to constitute an
   exhaustive list or an authoritative source for any of the protocol
   information given.  However, any protocol that can encapsulate other
   protocols must be documented here in order to encode the children
   identifiers into protocolDirID strings. Leaf protocols should be
   documented as well, but an implementation can identify a leaf
   protocol even if it isn't listed here (as long as the parent is
   documented).

3.1.1.  The TCP/IP protocol stack

arp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "An Address Resolution Protocol message (request or response).
       This protocol does not include Reverse ARP (RARP) packets, which
       are counted separately."
    REFERENCE
       "RFC 826 [RFC826] defines the Address Resolution Protocol."



Bierman, et al.              Informational                      [Page 5]

RFC 2896                     RMON PI Macros                  August 2000


    ::= {
     ether2 0x806,   -- [ 0.0.8.6 ]
     snap   0x806,
     802-1Q 0x806    -- [ 0.0.8.6 ]
    }

ip PROTOCOL-IDENTIFIER
    PARAMETERS {
       countsFragments(0)  -- This parameter applies to all child
                           -- protocols.
    }
    ATTRIBUTES {
     hasChildren(0),
     addressRecognitionCapable(1)
    }
    DESCRIPTION
       "The protocol identifiers for the Internet Protocol (IP). Note
       that IP may be encapsulated within itself, so more than one of
       the following identifiers may be present in a particular
       protocolDirID string."
    CHILDREN
       "Children of 'ip' are selected by the value in the Protocol field
       (one octet), as defined in the PROTOCOL NUMBERS table within the
       Assigned Numbers Document.

       The value of the Protocol field is encoded in an octet string as
       [ 0.0.0.a ], where 'a' is the protocol field .

       Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
       where 'a' is the protocol field value.  For example, a
       protocolDirID-fragment value of:
          0.0.0.1.0.0.8.0.0.0.0.1

       defines an encapsulation of ICMP (ether2.ip.icmp)"
    ADDRESS-FORMAT
       "4 octets of the IP address, in network byte order.  Each ip
       packet contains two addresses, the source address and the
       destination address."
    DECODING
       "Note: ether2.ip.ipip4.udp is a different protocolDirID than
       ether2.ip.udp, as identified in the protocolDirTable.  As such,
       two different local protocol index values will be assigned by the
       agent. E.g. (full INDEX values shown):
        ether2.ip.ipip4.udp =
            16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
        ether2.ip.udp =
            12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
    REFERENCE



Bierman, et al.              Informational                      [Page 6]

RFC 2896                     RMON PI Macros                  August 2000


       "RFC 791 [RFC791] defines the Internet Protocol; The following
       URL defines the authoritative repository for the PROTOCOL NUMBERS
       Table:

          ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
    ::= {
       ether2     0x0800,
       llc        0x06,
       snap       0x0800,
          -- ip         4,           ** represented by the ipip4 macro
          -- ip         94,          ** represented by the ipip macro
       802-1Q     0x0800,         -- [0.0.8.0]
       802-1Q     0x02000006      -- 1Q-LLC [2.0.0.6]
    }

 -- ****************************************************************
 --
 --                        Children of IP
 --
 -- ****************************************************************

icmp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Internet Message Control Protocol"
    REFERENCE
       "RFC 792 [RFC792] defines the Internet Control Message Protocol."
    ::= {
     ip 1,
     ipip4 1,
     ipip 1
    }

igmp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Internet Group Management Protocol; IGMP is used by IP hosts to
       report their host group memberships to any immediately-
       neighboring multicast routers."
    REFERENCE
       "Appendix A of Host Extensions for IP Multicasting [RFC1112]
       defines the Internet Group Management Protocol."
    ::= {
     ip 2,
     ipip4 2,
     ipip 2



Bierman, et al.              Informational                      [Page 7]

RFC 2896                     RMON PI Macros                  August 2000


    }

ggp PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Gateway-to-Gateway Protocol; DARPA Internet Gateway
       (historical)"
    REFERENCE
       "RFC 823 [RFC823] defines the Gateway-to-Gateway Protocol."
    ::= {
     ip 3,
     ipip4 3,
     ipip 3
    }

ipip4 PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
     hasChildren(0),
     addressRecognitionCapable(1)
    }
    DESCRIPTION
       "IP in IP Tunneling"
    CHILDREN
       "Children of 'ipip4' are selected and encoded in the same manner
       as children of IP."
    ADDRESS-FORMAT
       "The 'ipip4' address format is the same as the IP address
       format."
    DECODING
       "Note: ether2.ip.ipip4.udp is a different protocolDirID than
       ether2.ip.udp, as identified in the protocolDirTable.  As such,
       two different local protocol index values will be assigned by the
       agent. E.g. (full INDEX values shown):
        ether2.ip.ipip4.udp =
            16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
        ether2.ip.udp =
            12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
    REFERENCE
       "RFC 1853 [RFC1853] defines IP in IP over Protocol 4."
    ::= {
     ip 4,
     ipip4 4,
     ipip 4
    }

st PROTOCOL-IDENTIFIER



Bierman, et al.              Informational                      [Page 8]

RFC 2896                     RMON PI Macros                  August 2000


    PARAMETERS { }
    ATTRIBUTES { }
    DESCRIPTION
       "Internet Stream Protocol Version 2 (ST2); (historical) ST2 is an
       experimental resource reservation protocol intended to provide
       end-to-end real-time guarantees over an internet."
    REFERENCE
       "RFC 1819 [RFC1819] defines version 2 of the Internet Stream
       Protocol."
    ::= {
     ip 5,
     ipip4 5,
     ipip 5
    }

tcp  PROTOCOL-IDENTIFIER
    PARAMETERS { }
    ATTRIBUTES {
      hasChildren(0)
    }
    DESCRIPTION
       "Transmission Control Protocol"
    CHILDREN
       "Children of TCP are identified by the 16 bit Source or
       Destination Port value as specified in RFC 793. They are encoded
       as [ 0.0.a.b], where 'a' is the MSB and 'b' is the LSB of the
       port value. Both bytes are encoded in network byte order.  For
       example, a protocolDirId-fragment of:
           0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23