⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1229.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 3 页
字号:
Network Working Group                              K. McCloghrie, EditorRequest for Comments: 1229                      Hughes LAN Systems, Inc.                                                                May 1991                Extensions to the Generic-Interface MIBStatus of this Memo   This RFC contains definitions of managed objects used as experimental   extensions to the generic interfaces structure of MIB-II.  This memo   is a product of the SNMP Working Group of the Internet Engineering   Task Force (IETF).  This RFC specifies an IAB standards track   protocol for the Internet community, and requests discussion and   suggestions for improvements.  Please refer to the current edition of   the "IAB Official Protocol Standards" for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Table of Contents   1. Abstract ..............................................    1   2. The Network Management Framework.......................    1   3. Objects ...............................................    2   4. Overview ..............................................    3   4.1 Generic Interface Extension Table ....................    3   4.2 Generic Interface Test Table .........................    3   4.3 Generic Receive Address Table ........................    4   5. Definitions ...........................................    5   6. Acknowledgements ......................................   14   7. References ............................................   15   8. Security Considerations................................   15   9. Author's Address.......................................   161.  Abstract   This memo defines an experimental portion of the Management   Information Base (MIB) for use with network management protocols in   TCP/IP-based internets.  In particular, it defines managed object   types as experimental extensions to the generic interfaces structure   of MIB-II.2.  The Network Management Framework   The Internet-standard Network Management Framework consists of three   components.  They are:      RFC 1155 which defines the SMI, the mechanisms used for describing      and naming objects for the purpose of management.  RFC 1212SNMP Working Group                                              [Page 1]RFC 1229                Interface MIB Extensions                May 1991      defines a more concise description mechanism, which is wholly      consistent with the SMI.      RFC 1156 which defines MIB-I, the core set of managed objects for      the Internet suite of protocols.  RFC 1213, defines MIB-II, an      evolution of MIB-I based on implementation experience and new      operational requirements.      RFC 1157 which defines the SNMP, the protocol used for network      access to managed objects.   The Framework permits new objects to be defined for the purpose of   experimentation and evaluation.3.  Objects   Managed objects are accessed via a virtual information store, termed   the Management Information Base or MIB.  Objects in the MIB are   defined using the subset of Abstract Syntax Notation One (ASN.1) [7]   defined in the SMI.  In particular, each object has a name, a syntax,   and an encoding.  The name is an object identifier, an   administratively assigned name, which specifies an object type.  The   object type together with an object instance serves to uniquely   identify a specific instantiation of the object.  For human   convenience, we often use a textual string, termed the OBJECT   DESCRIPTOR, to also refer to the object type.   The syntax of an object type defines the abstract data structure   corresponding to that object type.  The ASN.1 language is used for   this purpose.  However, the SMI [3] purposely restricts the ASN.1   constructs which may be used.  These restrictions are explicitly made   for simplicity.   The encoding of an object type is simply how that object type is   represented using the object type's syntax.  Implicitly tied to the   notion of an object type's syntax and encoding is how the object type   is represented when being transmitted on the network.   The SMI specifies the use of the basic encoding rules of ASN.1 [8],   subject to the additional requirements imposed by the SNMP.   Section 5 contains the specification of all object types in this   section of the MIB.  The object types are defined using the   conventions specified in the SMI, as amended by the extensions   specified in [9].SNMP Working Group                                              [Page 2]RFC 1229                Interface MIB Extensions                May 19914.  Overview   The Internet Standard MIB [4,6] contains a group of management   objects pertaining to a network device's generic network   interface(s).  These objects are generic in the sense that they apply   to all network interfaces, irrespective of the type of communication   media and protocols used on such interfaces.  This has proved to be   necessary but not sufficient; there are efforts underway to define   additional MIB objects which are specific to particular media and   lower-level (subnetwork-layer and below) protocol stacks.   However, some of these efforts have identified objects which are   required (or at least useful), but are not specific to the   interface-type on which the effort is focusing.  In order to avoid   redundancy, it is better that such objects be defined as extensions   to the generic interface group, rather than defined in multiple   specific-interface-type MIBs.   This memo defines the resultant extensions to the generic interface   group.  These extensions are spread over three tables: the generic   Interface Extension table, the generic Interface Test table, and the   generic Receive Address table.4.1.  Generic Interface Extension Table   This table consists of new objects applicable to all types of   subnetwork interface.4.2.  Generic Interface Test Table   This section defines objects which allow a network manager to   instruct an agent to test an interface for various faults.  A few   common types of tests are defined in this document but most will be   defined elsewhere, dependent on the particular type of interface.   After testing, the object ifExtnsTestResult can be read to determine   the outcome.  If an agent cannot perform the test, ifExtnsTestResult   is set to so indicate.  The object ifExtnsTestCode can be used to   provide further test-specific or interface-specific (or even   enterprise-specific) information concerning the outcome of the test.   Only one test can be in progress on each interface at any one time.   If one test is in progress when another test is invoked, the second   test is rejected.  Some agents may reject a test when a prior test is   active on another interface.   When a test is invoked, the identity of the originator of the request   and the request-id are saved by the agent in the objects   ifExtnsTestRequestId and ifExtnsTestCommunity.  These values remain   set until the next test is invoked.  In the (rare) event that theSNMP Working Group                                              [Page 3]RFC 1229                Interface MIB Extensions                May 1991   invocation of tests by two network managers were to overlap, then   there would be a possibility that the first test's results might be   overwritten by the second test's results prior to the first results   being read.  This unlikely circumstance can be detected by a network   manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId at   the same time as the test results are retrieved, and ensuring that   the results are for the desired request.   In general, a Management station must not retransmit a request to   invoke a test for which it does not receive a response; instead, it   properly inspects an agent's MIB to determine if the invocation was   successful.  The invocation request is retransmitted only if the   invocation was unsuccessful.   Some tests may require the interface to be taken off-line or may even   require the agent to be rebooted after completion of the test.  In   these circumstances, communication with the management station   invoking the test may be lost until after completion of the test.   The agent should make every effort to transmit a response to the   request that invoked the test prior to losing communication.  When   the agent is restored to normal service, the results of the test are   properly made available in the appropriate objects.  Note that this   requires that the ifIndex value assigned to an interface must be   unchanged even if the test causes a reboot.  An agent must reject any   test for which it cannot, perhaps due to resource constraints, make   available at least the minimum amount of information after that test   completes.4.3.  Generic Receive Address Table   This table contains objects relating to an interface's support for   receiving packets/frames at more than one address on the same   interface.SNMP Working Group                                              [Page 4]RFC 1229                Interface MIB Extensions                May 19915.  Definitions          RFC1229-MIB DEFINITIONS ::= BEGIN          --        Extensions to MIB-II's Generic Interface Table          IMPORTS                  experimental, Counter         FROM RFC1155-SMI                  DisplayString, PhysAddress    FROM RFC1213-MIB                  OBJECT-TYPE                   FROM RFC-1212;          ifExtensions  OBJECT IDENTIFIER ::= { experimental 6 }          --   Generic Interface Extension Table          --          --  This group of objects is mandatory for all types of          --  subnetwork interface.          ifExtnsTable  OBJECT-TYPE                  SYNTAX SEQUENCE OF IfExtnsEntry                  ACCESS not-accessible                  STATUS mandatory                  DESCRIPTION                         "A list of interfaces extension entries.                          The number of entries is given by the value                          of ifNumber, defined in [4,6]."                  ::= { ifExtensions 1 }          ifExtnsEntry  OBJECT-TYPE                  SYNTAX IfExtnsEntry                  ACCESS not-accessible                  STATUS mandatory                  DESCRIPTION                         "An extension to the interfaces entry,                          defined in [4,6], containing additional                          objects at the subnetwork layer and below                          for a particular interface."                  INDEX  { ifExtnsIfIndex }                  ::= { ifExtnsTable 1 }          IfExtnsEntry ::=                  SEQUENCE {                      ifExtnsIfIndexSNMP Working Group                                              [Page 5]RFC 1229                Interface MIB Extensions                May 1991                          INTEGER,                      ifExtnsChipSet                          OBJECT IDENTIFIER,                      ifExtnsRevWare                          DisplayString,                      ifExtnsMulticastsTransmittedOks                          Counter,                      ifExtnsBroadcastsTransmittedOks                          Counter,                      ifExtnsMulticastsReceivedOks                          Counter,                      ifExtnsBroadcastsReceivedOks                          Counter,                      ifExtnsPromiscuous

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -