EXHIBIT E
`
`
`
`EXHIBIT EEXHIBIT E
`
`
`
`
`
`

`
`
`
`Network Working Group K. McCloghrie
`Request for Comments: 1213 Hughes LAN Systems, Inc.
`Obsoletes: RFC 1158 M. Rose
` Performance Systems International
` Editors
` March 1991
`
`
`
` Management Information Base for Network Management
` of TCP/IP-based internets:
` MIB-II
`
`Status of this Memo
` This memo defines the second version of the Management Information
` Base (MIB-II) for use with network management protocols in TCP/IP-
` based internets. 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............................................... 2
` 2. Introduction .......................................... 2
` 3. Changes from RFC 1156 ................................. 3
` 3.1 Deprecated Objects ................................... 3
` 3.2 Display Strings ...................................... 4
` 3.3 Physical Addresses ................................... 4
` 3.4 The System Group ..................................... 5
` 3.5 The Interfaces Group ................................. 5
` 3.6 The Address Translation Group ........................ 6
` 3.7 The IP Group ......................................... 6
` 3.8 The ICMP Group ....................................... 7
` 3.9 The TCP Group ........................................ 7
` 3.10 The UDP Group ....................................... 7
` 3.11 The EGP Group ....................................... 7
` 3.12 The Transmission Group .............................. 8
` 3.13 The SNMP Group ...................................... 8
` 3.14 Changes from RFC 1158 ................. ............. 9
` 4. Objects ............................................... 10
` 4.1 Format of Definitions ................................ 10
` 5. Overview .............................................. 10
` 6. Definitions ........................................... 12
` 6.1 Textual Conventions .................................. 12
` 6.2 Groups in MIB-II ..................................... 13
` 6.3 The System Group ..................................... 13
`
`
`
`
`
`
`
`SNMP Working Group [Page 1]
`
`

`
`
`RFC 1213 MIB-II March 1991
`
`
`
` 6.4 The Interfaces Group ................................. 16
` 6.5 The Address Translation Group ........................ 23
` 6.6 The IP Group ......................................... 26
` 6.7 The ICMP Group ....................................... 41
` 6.8 The TCP Group ........................................ 46
` 6.9 The UDP Group ........................................ 52
` 6.10 The EGP Group ....................................... 54
` 6.11 The Transmission Group .............................. 60
` 6.12 The SNMP Group ...................................... 60
` 7. Acknowledgements ...................................... 67
` 8. References ............................................ 69
` 9. Security Considerations ............................... 70
` 10. Authors' Addresses ................................... 70
`
`1. Abstract
` This memo defines the second version of the Management Information
` Base (MIB-II) for use with network management protocols in TCP/IP-
` based internets. In particular, together with its companion memos
` which describe the structure of management information (RFC 1155)
` along with the network management protocol (RFC 1157) for TCP/IP-
` based internets, these documents provide a simple, workable
` architecture and system for managing TCP/IP-based internets and in
` particular the Internet community.
`
`2. Introduction
` As reported in RFC 1052, IAB Recommendations for the Development of
` Internet Network Management Standards [1], a two-prong strategy for
` network management of TCP/IP-based internets was undertaken. In the
` short-term, the Simple Network Management Protocol (SNMP) was to be
` used to manage nodes in the Internet community. In the long-term,
` the use of the OSI network management framework was to be examined.
` Two documents were produced to define the management information: RFC
` 1065, which defined the Structure of Management Information (SMI)
` [2], and RFC 1066, which defined the Management Information Base
` (MIB) [3]. Both of these documents were designed so as to be
` compatible with both the SNMP and the OSI network management
` framework.
` This strategy was quite successful in the short-term: Internet-based
` network management technology was fielded, by both the research and
` commercial communities, within a few months. As a result of this,
` portions of the Internet community became network manageable in a
` timely fashion.
` As reported in RFC 1109, Report of the Second Ad Hoc Network
` Management Review Group [4], the requirements of the SNMP and the OSI
`
`
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 2]
`
`
`

`
`RFC 1213 MIB-II March 1991
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` network management frameworks were more different than anticipated.
` As such, the requirement for compatibility between the SMI/MIB and
` both frameworks was suspended. This action permitted the operational
` network management framework, the SNMP, to respond to new operational
` needs in the Internet community by producing this document.
` As such, the current network management framework for TCP/IP- based
` internets consists of: Structure and Identification of Management
` Information for TCP/IP-based internets, RFC 1155 [12], which
` describes how managed objects contained in the MIB are defined;
` Management Information Base for Network Management of TCP/IP-based
` internets: MIB-II, this memo, which describes the managed objects
` contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple
` Network Management Protocol, RFC 1098 [5], which defines the protocol
` used to manage these objects.
`
`3. Changes from RFC 1156
` Features of this MIB include:
` (1) incremental additions to reflect new operational
` requirements;
` (2) upwards compatibility with the SMI/MIB and the SNMP;
` (3) improved support for multi-protocol entities; and,
` (4) textual clean-up of the MIB to improve clarity and
` readability.
` The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:
` mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
` which is identical to the prefix used in MIB-I.
`
`3.1. Deprecated Objects
` In order to better prepare implementors for future changes in the
` MIB, a new term "deprecated" may be used when describing an object.
` A deprecated object in the MIB is one which must be supported, but
` one which will most likely be removed from the next version of the
` MIB (e.g., MIB-III).
` MIB-II marks one object as being deprecated:
` atTable
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 3]
`
`RFC 1213 MIB-II March 1991
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` As a result of deprecating the atTable object, the entire Address
` Translation group is deprecated.
` Note that no functionality is lost with the deprecation of these
` objects: new objects providing equivalent or superior functionality
` are defined in MIB-II.
`
`3.2. Display Strings
` In the past, there have been misinterpretations of the MIB as to when
` a string of octets should contain printable characters, meant to be
` displayed to a human. As a textual convention in the MIB, the
` datatype
` DisplayString ::=
` OCTET STRING
` is introduced. A DisplayString is restricted to the NVT ASCII
` character set, as defined in pages 10-11 of [6].
` The following objects are now defined in terms of DisplayString:
` sysDescr
` ifDescr
` It should be noted that this change has no effect on either the
` syntax nor semantics of these objects. The use of the DisplayString
` notation is merely an artifact of the explanatory method used in
` MIB-II and future MIBs.
` Further it should be noted that any object defined in terms of OCTET
` STRING may contain arbitrary binary data, in which each octet may
` take any value from 0 to 255 (decimal).
`
`3.3. Physical Addresses
` As a further, textual convention in the MIB, the datatype
` PhysAddress ::=
` OCTET STRING
` is introduced to represent media- or physical-level addresses.
` The following objects are now defined in terms of PhysAddress:
` ifPhysAddress
` atPhysAddress
` ipNetToMediaPhysAddress
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 4]
`
`RFC 1213 MIB-II March 1991
`
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` It should be noted that this change has no effect on either the
` syntax nor semantics of these objects. The use of the PhysAddress
` notation is merely an artifact of the explanatory method used in
` MIB-II and future MIBs.
`
`3.4. The System Group
` Four new objects are added to this group:
` sysContact
` sysName
` sysLocation
` sysServices
` These provide contact, administrative, location, and service
` information regarding the managed node.
`
`3.5. The Interfaces Group
` The definition of the ifNumber object was incorrect, as it required
` all interfaces to support IP. (For example, devices without IP, such
` as MAC-layer bridges, could not be managed if this definition was
` strictly followed.) The description of the ifNumber object is
` changed accordingly.
` The ifTable object was mistaken marked as read-write, it has been
` (correctly) re-designated as not-accessible. In addition, several
` new values have been added to the ifType column in the ifTable
` object:
` ppp(23)
` softwareLoopback(24)
` eon(25)
` ethernet-3Mbit(26)
` nsip(27)
` slip(28)
` ultra(29)
` ds3(30)
` sip(31)
` frame-relay(32)
` Finally, a new column has been added to the ifTable object:
` ifSpecific
` which provides information about information specific to the media
` being used to realize the interface.
`
`
`
`
`
`SNMP Working Group [Page 5]
`
`RFC 1213 MIB-II March 1991
`
`
`
`

`
`3.6. The Address Translation Group
` In MIB-I this group contained a table which permitted mappings from
` network addresses (e.g., IP addresses) to physical addresses (e.g.,
` MAC addresses). Experience has shown that efficient implementations
` of this table make two assumptions: a single network protocol
` environment, and mappings occur only from network address to physical
` address.
` The need to support multi-protocol nodes (e.g., those with both the
` IP and CLNP active), and the need to support the inverse mapping
` (e.g., for ES-IS), have invalidated both of these assumptions. As
` such, the atTable object is declared deprecated.
` In order to meet both the multi-protocol and inverse mapping
` requirements, MIB-II and its successors will allocate up to two
` address translation tables inside each network protocol group. That
` is, the IP group will contain one address translation table, for
` going from IP addresses to physical addresses. Similarly, when a
` document defining MIB objects for the CLNP is produced (e.g., [7]),
` it will contain two tables, for mappings in both directions, as this
` is required for full functionality.
` It should be noted that the choice of two tables (one for each
` direction of mapping) provides for ease of implementation in many
` cases, and does not introduce undue burden on implementations which
` realize the address translation abstraction through a single internal
` table.
`
`3.7. The IP Group
` The access attribute of the variable ipForwarding has been changed
` from read-only to read-write.
` In addition, there is a new column to the ipAddrTable object,
` ipAdEntReasmMaxSize
` which keeps track of the largest IP datagram that can be re-assembled
` on a particular interface.
` The descriptor of the ipRoutingTable object has been changed to
` ipRouteTable for consistency with the other IP routing objects.
` There are also three new columns in the ipRouteTable object,
` ipRouteMask
` ipRouteMetric5
` ipRouteInfo
`
`
`
`
`
`
`
`SNMP Working Group [Page 6]
`
`RFC 1213 MIB-II March 1991
`
`
`
` the first is used for IP routing subsystems that support arbitrary
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
` subnet masks, and the latter two are IP routing protocol-specific.
` Two new objects are added to the IP group:
` ipNetToMediaTable
` ipRoutingDiscards
` the first is the address translation table for the IP group
` (providing identical functionality to the now deprecated atTable in
` the address translation group), and the latter provides information
` when routes are lost due to a lack of buffer space.
`
`3.8. The ICMP Group
` There are no changes to this group.
`
`3.9. The TCP Group
` Two new variables are added:
` tcpInErrs
` tcpOutRsts
` which keep track of the number of incoming TCP segments in error and
` the number of resets generated by a TCP.
`
`3.10. The UDP Group
` A new table:
` udpTable
` is added.
`
`3.11. The EGP Group
` Experience has indicated a need for additional objects that are
` useful in EGP monitoring. In addition to making several additions to
` the egpNeighborTable object, i.e.,
` egpNeighAs
` egpNeighInMsgs
` egpNeighInErrs
` egpNeighOutMsgs
` egpNeighOutErrs
` egpNeighInErrMsgs
` egpNeighOutErrMsgs
`
`
`
`
`
`
`
`SNMP Working Group [Page 7]
`
`RFC 1213 MIB-II March 1991
`
`
`
` egpNeighStateUps
` egpNeighStateDowns
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
` egpNeighIntervalHello
` egpNeighIntervalPoll
` egpNeighMode
` egpNeighEventTrigger
` a new variable is added:
` egpAs
` which gives the autonomous system associated with this EGP entity.
`
`3.12. The Transmission Group
` MIB-I was lacking in that it did not distinguish between different
` types of transmission media. A new group, the Transmission group, is
` allocated for this purpose:
` transmission OBJECT IDENTIFIER ::= { mib-2 10 }
` When Internet-standard definitions for managing transmission media
` are defined, the transmission group is used to provide a prefix for
` the names of those objects.
` Typically, such definitions reside in the experimental portion of the
` MIB until they are "proven", then as a part of the Internet
` standardization process, the definitions are accordingly elevated and
` a new object identifier, under the transmission group is defined. By
` convention, the name assigned is:
` type OBJECT IDENTIFIER ::= { transmission number }
` where "type" is the symbolic value used for the media in the ifType
` column of the ifTable object, and "number" is the actual integer
` value corresponding to the symbol.
`
`3.13. The SNMP Group
` The application-oriented working groups of the IETF have been tasked
` to be receptive towards defining MIB variables specific to their
` respective applications.
` For the SNMP, it is useful to have statistical information. A new
` group, the SNMP group, is allocated for this purpose:
` snmp OBJECT IDENTIFIER ::= { mib-2 11 }
`
`
`
`
`
`
`
`SNMP Working Group [Page 8]
`
`RFC 1213 MIB-II March 1991
`
`
`
`3.14. Changes from RFC 1158
` Features of this MIB include:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`
`
`
`
`
`
`
`
`
`
` (1) The managed objects in this document have been defined
` using the conventions defined in the Internet-standard
` SMI, as amended by the extensions specified in [14]. It
` must be emphasized that definitions made using these
` extensions are semantically identically to those in RFC
` 1158.
` (2) The PhysAddress textual convention has been introduced to
` represent media addresses.
` (3) The ACCESS clause of sysLocation is now read-write.
` (4) The definition of sysServices has been clarified.
` (5) New ifType values (29-32) have been defined. In
` addition, the textual-descriptor for the DS1 and E1
` interface types has been corrected.
` (6) The definition of ipForwarding has been clarified.
` (7) The definition of ipRouteType has been clarified.
` (8) The ipRouteMetric5 and ipRouteInfo objects have been
` defined.
` (9) The ACCESS clause of tcpConnState is now read-write, to
` support deletion of the TCB associated with a TCP
` connection. The definition of this object has been
` clarified to explain this usage.
` (10) The definition of egpNeighEventTrigger has been
` clarified.
` (11) The definition of several of the variables in the new
` snmp group have been clarified. In addition, the
` snmpInBadTypes and snmpOutReadOnlys objects are no longer
` present. (However, the object identifiers associated
` with those objects are reserved to prevent future use.)
` (12) The definition of snmpInReadOnlys has been clarified.
` (13) The textual descriptor of the snmpEnableAuthTraps has
` been changed to snmpEnableAuthenTraps, and the definition
` has been clarified.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 9]
`
`RFC 1213 MIB-II March 1991
`
`
`
` (14) The ipRoutingDiscards object was added.
` (15) The optional use of an implementation-dependent, small
` positive integer was disallowed when identifying
`
`
`
`

`
` instances of the IP address and routing tables.
`
`4. 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) [8]
` 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 [12] 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 [9],
` subject to the additional requirements imposed by the SNMP.
`
`4.1. Format of Definitions
` Section 6 contains contains the specification of all object types
` contained in this MIB module. The object types are defined using the
` conventions defined in the SMI, as amended by the extensions
` specified in [14].
`
`5. Overview
` Consistent with the IAB directive to produce simple, workable systems
` in the short-term, the list of managed objects defined here, has been
` derived by taking only those elements which are considered essential.
` This approach of taking only the essential objects is NOT
` restrictive, since the SMI defined in the companion memo provides
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 10]
`
`RFC 1213 MIB-II March 1991
`
`
`
` three extensibility mechanisms: one, the addition of new standard
` objects through the definitions of new versions of the MIB; two, the
` addition of widely-available but non-standard objects through the
` experimental subtree; and three, the addition of private objects
` through the enterprises subtree. Such additional objects can not
`
`

`
` only be used for vendor-specific elements, but also for
` experimentation as required to further the knowledge of which other
` objects are essential.
` The design of MIB-II is heavily influenced by the first extensibility
` mechanism. Several new variables have been added based on
` operational experience and need. Based on this, the criteria for
` including an object in MIB-II are remarkably similar to the MIB-I
` criteria:
` (1) An object needed to be essential for either fault or
` configuration management.
` (2) Only weak control objects were permitted (by weak, it is
` meant that tampering with them can do only limited
` damage). This criterion reflects the fact that the
` current management protocols are not sufficiently secure
` to do more powerful control operations.
` (3) Evidence of current use and utility was required.
` (4) In MIB-I, an attempt was made to limit the number of
` objects to about 100 to make it easier for vendors to
` fully instrument their software. In MIB-II, this limit
` was raised given the wide technological base now
` implementing MIB-I.
` (5) To avoid redundant variables, it was required that no
` object be included that can be derived from others in the
` MIB.
` (6) Implementation specific objects (e.g., for BSD UNIX) were
` excluded.
` (7) It was agreed to avoid heavily instrumenting critical
` sections of code. The general guideline was one counter
` per critical section per layer.
` MIB-II, like its predecessor, the Internet-standard MIB, contains
` only essential elements. There is no need to allow individual
` objects to be optional. Rather, the objects are arranged into the
` following groups:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 11]
`
`RFC 1213 MIB-II March 1991
`
`
`
` - System
` - Interfaces
` - Address Translation (deprecated)
` - IP
` - ICMP
` - TCP
`
`

`
` - UDP
` - EGP
` - Transmission
` - SNMP
` These groups are the basic unit of conformance: This method is as
` follows: if the semantics of a group is applicable to an
` implementation, then it must implement all objects in that group.
` For example, an implementation must implement the EGP group if and
` only if it implements the EGP.
` There are two reasons for defining these groups: to provide a means
` of assigning object identifiers; and, to provide a method for
` implementations of managed agents to know which objects they must
` implement.
`
`6. Definitions
` RFC1213-MIB DEFINITIONS ::= BEGIN
` IMPORTS
` mgmt, NetworkAddress, IpAddress, Counter, Gauge,
` TimeTicks
` FROM RFC1155-SMI
` OBJECT-TYPE
` FROM RFC-1212;
` -- This MIB module uses the extended OBJECT-TYPE macro as
` -- defined in [14];
`
`
`
`
`
`
`
`
`
`
`
`
`
` -- MIB-II (same prefix as MIB-I)
` mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
` -- textual conventions
` DisplayString ::=
` OCTET STRING
` -- This data type is used to model textual information taken
` -- from the NVT ASCII character set. By convention, objects
` -- with this syntax are declared as having
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 12]
`
`RFC 1213 MIB-II March 1991
`
`
`
` --
` -- SIZE (0..255)
` PhysAddress ::=
` OCTET STRING
` -- This data type is used to model media addresses. For many
` -- types of media, this will be in a binary representation.
`
`
`
`

`
` -- For example, an ethernet address would be represented as
` -- a string of 6 octets.
`
`
`
` -- groups in MIB-II
` system OBJECT IDENTIFIER ::= { mib-2 1 }
` interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
` at OBJECT IDENTIFIER ::= { mib-2 3 }
` ip OBJECT IDENTIFIER ::= { mib-2 4 }
` icmp OBJECT IDENTIFIER ::= { mib-2 5 }
` tcp OBJECT IDENTIFIER ::= { mib-2 6 }
` udp OBJECT IDENTIFIER ::= { mib-2 7 }
` egp OBJECT IDENTIFIER ::= { mib-2 8 }
` -- historical (some say hysterical)
` -- cmot OBJECT IDENTIFIER ::= { mib-2 9 }
` transmission OBJECT IDENTIFIER ::= { mib-2 10 }
` snmp OBJECT IDENTIFIER ::= { mib-2 11 }
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` -- the System group
` -- Implementation of the System group is mandatory for all
` -- systems. If an agent is not configured to have a value
` -- for any of these variables, a string of length 0 is
` -- returned.
` sysDescr OBJECT-TYPE
` SYNTAX DisplayString (SIZE (0..255))
` ACCESS read-only
` STATUS mandatory
`
`
`
`
`
`SNMP Working Group [Page 13]
`
`RFC 1213 MIB-II March 1991
`
`
`
` DESCRIPTION
` "A textual description of the entity. This value
` should include the full name and version
` identification of the system's hardware type,
` software operating-system, and networking
` software. It is mandatory that this only contain
` printable ASCII characters."
` ::= { system 1 }
`
`
`
`

`
`
`
`
`
`
`
`
`
` sysObjectID OBJECT-TYPE
` SYNTAX OBJECT IDENTIFIER
` ACCESS read-only
` STATUS mandatory
` DESCRIPTION
` "The vendor's authoritative identification of the
` network management subsystem contained in the
` entity. This value is allocated within the SMI
` enterprises subtree (1.3.6.1.4.1) and provides an
` easy and unambiguous means for determining `what
` kind of box' is being managed. For example, if
` vendor `Flintstones, Inc.' was assigned the
` subtree 1.3.6.1.4.1.4242, it could assign the
` identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
` Router'."
` ::= { system 2 }
` sysUpTime OBJECT-TYPE
` SYNTAX TimeTicks
` ACCESS read-only
` STATUS mandatory
` DESCRIPTION
` "The time (in hundredths of a second) since the
` network management portion of the system was last
` re-initialized."
` ::= { system 3 }
` sysContact OBJECT-TYPE
` SYNTAX DisplayString (SIZE (0..255))
` ACCESS read-write
` STATUS mandatory
` DESCRIPTION
` "The textual identification of the contact person
` for this managed node, together with information
` on how to contact this person."
` ::= { system 4 }
` sysName OBJECT-TYPE
` SYNTAX DisplayString (SIZE (0..255))
`
`
`
`SNMP Working Group [Page 14]
`
`RFC 1213 MIB-II March 1991
`
`
`
` ACCESS read-write
` STATUS mandatory
` DESCRIPTION
` "An administratively-assigned name for this
` managed node. By convention, this is the node's
` fully-qualified domain name."
` ::= { system 5 }
` sysLocation OBJECT-TYPE
`
`
`
`

`
` SYNTAX DisplayString (SIZE (0..255))
` ACCESS read-write
` STATUS mandatory
` DESCRIPTION
` "The physical location of this node (e.g.,
` `telephone closet, 3rd floor')."
` ::= { system 6 }
` sysServices OBJECT-TYPE
` SYNTAX INTEGER (0..127)
` ACCESS read-only
` STATUS mandatory
` DESCRIPTION
` "A value which indicates the set of services that
` this entity primarily offers.
` The value is a sum. This sum initially takes the
` value zero, Then, for each layer, L, in the range
` 1 through 7, that this node performs transactions
` for, 2 raised to (L - 1) is added to the sum. For
` example, a node which performs primarily routing
` functions would have a value of 4 (2^(3-1)). In
` contrast, a node which is a host offering
` application services would have a value of 72
` (2^(4-1) + 2^(7-1)). Note that in the context of
` the Internet suite of protocols, values should be
` calculated accordingly:
` layer functionality
` 1 physical (e.g., repeaters)
` 2 datalink/subnetwork (e.g., bridges)
` 3 internet (e.g., IP gateways)
` 4 end-to-end (e.g., IP hosts)
` 7 applications (e.g., mail relays)
` For systems including OSI protocols, layers 5 and
` 6 may also be counted."
` ::= { system 7 }
`
`
`
`
`
`
`
`
`
`
`
`SNMP Working Group [Page 15]
`
`RFC 1213 MIB-II March 1991
`
`
`
` -- the Interfaces group
` -- Implementation of the Interfaces group is mandatory for
` -- all systems.
` ifNumber OBJECT-TYPE
` SYNTAX INTEGER
` ACCESS read-only
` STATUS mandatory
` DESCRIPTION
`
`
`
`
`
`

`
` "The number of network interfaces (regardless of
` their current state) present on this system."
` ::= { interfaces 1 }
`
` -- the Interfaces table
` -- The Interfaces table contains information on the entity's
` -- interfaces. Each interface is thought of as being
` -- attached to a `subnetwork'. Note that this term should
` -- not be confused with `subnet' which refers to an
` -- addressing partitioning scheme used in the Internet suite
` -- of protocols.
`