Rfc 1573 pdf

Please refer to the current edition of the "Internet Official Protocol Standards" STD 1 for the standardization state and status of this protocol.

Distribution of this memo is unlimited. Table of Contents 1. Interfaces Group Definitions Security Considerations Authors' Addresses In particular, it describes managed objects used for managing Network Interfaces.

This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer.

It proposes clarifications to, and extensions of, the architectural issues within the current model used for the 'interfaces' group. This memo also includes a MIB module. They are: o RFC which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. The Framework permits new objects to be defined for the purpose of experimentation and evaluation.

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 descriptor, to refer to the object type. Experience with the Interfaces Group One of the strengths of internetwork-layer protocols such as IP [ 6 ] is that they are designed to run over any network interface.

In achieving this, IP considers any and all protocols it runs over as a single "network interface" layer. A similar view is taken by other internetwork-layer protocols. This concept is represented in MIB-II by the 'interfaces' group which defines a generic set of managed objects such that any network interface can be managed in an interface-independent manner through these managed objects.

The 'interfaces' group provides the means for additional managed objects specific to particular types of network interface e. As a result, some of these media-specific MIB modules have assumed an evolution or loosening of the model. This memo is a proposal to document and standardize the evolution of the model and to fill in the gaps caused by that evolution.

A previous effort to extend the interfaces group resulted in the publication of RFC [ 7 ]. As part of defining the evolution of the interfaces group, this memo applies that evolution to, and thereby incorporates, the RFC extensions. The next sections discuss these. Interface Numbering MIB-II defines an object, ifNumber, whose value represents: "The number of network interfaces regardless of their current state present on this system. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization.

Interface Sub-Layers Experience in defining media-specific management information has shown the need to distinguish between the multiple sub-layers beneath the internetwork-layer. In addition, there is a need to manage these sub-layers in devices e. As such, a model of having a single conceptual row in the interfaces table MIB-II's ifTable represent a whole interface underneath the internetwork-layer, and having a single associated media-specific MIB module referenced via the ifType object is too simplistic.

A further problem arises with the value of the ifType object which has enumerated values for each type of interface. Each of these sub-layers has its own media-specific MIB module. If all of this is represented by a single conceptual row in the ifTable, then an enumerated value for ifType is needed for that specific combination which maps to the specific combination of media-specific MIBs. Furthermore, there is still a lack of a method to describe the relationship of all the sub-layers of the MIB stack.

An example of upward multiplexing is MLP Multi- Link-Procedure which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer s above.

An example of downward multiplexing would be several instances of PPP, each framed within a separate X. The current MIB structure does not allow for these sorts of relationships to be described. Virtual Circuits Several of the sub-layers for which media-specific MIB modules have been defined are connection oriented e. Experience has shown that each effort to define such a MIB module revisits the question of whether separate conceptual rows in the ifTable are needed for each virtual circuit.

Most, if not all, of these efforts to date have decided to have all virtual circuits reference a single conceptual row in the ifTable. Due to the packet-based nature of many of the objects in the ifTable, experience has shown that it is not appropriate to have a character-oriented sub-layer represented by a whole conceptual row in the ifTable. Experience has also shown that it is sometimes desirable to have some management information for bit-oriented interfaces, which are similarly difficult to represent by a whole conceptual row in the ifTable.

For example, to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data. A further complication is that some subnetwork technologies transmit data in fixed length transmission units. One example of such a technology is cell relay, and in particular Asynchronous Transfer Mode ATM , which transmits data in fixed-length cells.

Representing such a interface as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit e. Counter Size As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases.

For example, on an Ethernet, a stream of back-to-back, full-size packets will cause ifInOctets to wrap in just over 57 minutes. For FDDI, it will wrap in 5. For a 1-gigabit medium, the counter might wrap in as little as 34 seconds.

Requiring that interfaces be polled frequently enough not to miss a counter wrap will be increasingly problematic. Interface Speed Network speeds are increasing. Thus, ifSpeed will be of diminishing utility over the next several years.

In contrast, the ifExtensions MIB [ 7 ] defines one set of counters for multicast, and a separate set for broadcast packets. With the separate counters, the original combined counters become redundant. Addition of New ifType values Over time new ifType enumerated values have been needed for new interface types.

In the past, re-issuing of the MIB has occurred only after several years. As a result, different implementors have used it differently, and confusion has resulted. Interface Numbering One solution to the interface numbering problem would be to redefine ifNumber to be the largest value of ifIndex, but the utility of such an object is questionable, and such a re-definition would require ifNumber to be deprecated.

Thus, an improvement would be to deprecate ifNumber and not replace it. However, the deprecation of ifNumber would require a change to that portion of ifIndex's definition which refers to ifNumber. So, since the definition of ifIndex must be changed anyway in order to solve the problem, changes to ifNumber do not benefit the solution.

The solution adopted in this memo is to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition.

It could be argued that this is a change in the semantics of ifIndex; however, all existing implementations conform to this new definition, and in the interests of not requiring changes in existing implementations and in the many existing media-specific MIBs, it is proposed that this change does not require ifIndex to be deprecated. This solution also results in the possibility of "holes" in the ifTable i. The vital constancy requirement is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used by a different dynamically added interface until after the following re-initialization of the network management system.

This avoids the need for a priori assignment of ifIndex values for all possible interfaces which might be added dynamically. The exact meaning of a "different" interface is hard to define, and there will be gray areas. One important criterion is that a management station, not noticing that an interface has gone away and another come into existence, should not be confused when it calculates the difference between the counter values retrieved on successive polls for a particular ifIndex value.

However, any firm definition in this document would likely to turn out to be inadequate. A previously-unused value of ifIndex should be assigned to a dynamically added interface if: 1 the assignment of a previously-used ifIndex value to the interface could result in a discontinuity in the values of ifTable counters for that value of ifIndex; or, 2 an agent has no knowledge of whether the interface is the "same" or "different" from a previous interface incarnation.

Because of the restriction of the value of ifIndex to be less than ifNumber, interfaces have been numbered with small integer values. This has led to the ability by humans to use the ifIndex values as somewhat user-friendly names for network interfaces e. With the relaxation of the restriction on the value of ifIndex, there is now the possibility that ifIndex values could be assigned as very large numbers e. Such numbers would be much less user-friendly.

Therefore, this memo recommends that ifIndex values still be assigned as relatively small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous. Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces. This proposed change introduces a new problem of its own.

Previously, there usually was a simple, direct, mapping of interfaces to the physical ports on systems. This mapping would be based on the ifIndex value. However, by removing the previous restrictions on the values allowed for ifIndex, along with the interface sub-layer concept see the following section , mapping from interfaces to physical ports becomes increasingly problematic.

To address this issue, a new object, ifName, is added to the MIB. This object contains the device's name for the interface of which the relevant entry in the ifTable is a component. For example, if a router has an interface named wan1, which is composed of PPP running over an RS port, the ifName objects for the corresponding PPP and RS entries in the ifTable will contain the string "wan1".

Effectively, one conceptual row in the ifTable would represent each combination of sub-layers between the internetwork-layer and the wire. While this scheme has fewer drawbacks, it does not support downward multiplexing, such as PPP over MLP; since MLP makes two or more serial lines appear to the layers above as a single physical interface, PPP over MLP should appear to the internetwork-layer as a single interface.

However, this scheme would result in two or more conceptual rows in the ifTable and the internetwork-layer would run over both of them. This scheme also requires enumerated values of ifType for each combination of sub-layers.

The solution adopted in this memo is to have an individual conceptual row in the ifTable to represent each sub-layer and have a new separate MIB table the ifStackTable, see section 5 of this memo to identify the "superior" and "subordinate" sub-layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable.

This solution supports both upward and downward multiplexing. The new table ifStackTable need be referenced only to obtain information about layering. Enumerated values for ifType are required for each sub- layer only, not for combinations of them. However, this solution does require that the descriptions of some objects in the ifTable specifically, ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts be generalized so as to apply to any sub-layer rather than only to a sub-layer immediately beneath the network layer, as at present.

In addition, this adopted solution makes no requirement that a device, in which a sub-layer is instrumented by a conceptual row of the ifTable, be aware of whether an internetwork protocol runs on top of i.

In fact, the counters of packets received on an interface are defined as counting the number "delivered to a higher-layer protocol". For example, for the purposes of this definition, the forwarding module of a MAC-layer bridge is considered as a "higher-layer" to the MAC-layer of each port on the bridge. For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be considered the higher sub-layer to the serial interface.

For example, for the purposes of this definition, the local IP module would be considered the higher layer to a SLIP serial interface. Similarly, for output, the counters of packets transmitted out an interface are defined as counting the number "that higher-level protocols requested to be transmitted".

For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be a "higher layer" to the serial interface. For example, for the purposes of this definition, the local IP module would be considered the higher layer to an Ethernet interface. Guidance on Defining Sub-layers The designer of a media-specific MIB must decide whether to divide the interface into sub-layers, and if so, how to make the divisions.

The following guidance is offered to assist the media-specific MIB designer in these decisions. In general, the number of entries in the ifTable should be kept to the minimum required for network management. In particular, a group of related interfaces should be treated as a single interface with one entry in the ifTable providing that: 1 None of the group of interfaces performs multiplexing for any other interface in the agent, 2 There is a meaningful and useful way for all of the ifTable's information e.

Under these circumstances, there should be one entry in the ifTable for such a group of interfaces, and any internal structure which needs to be represented to network management should be captured in a MIB module specific to the particular type of interface. Note that application of bullet 2 above to the ifTable's ifType object requires that there is a meaningful media-specific MIB and a meaningful ifType value which apply to the group of interfaces as a whole.

Note that the sub-layers of an interface on one device will sometimes be different to the sub-layers of the interconnected interface of another device.

These guidelines are just that - guidelines. However, in so doing, the media- specific MIB MUST completely specify the sub-layering model used for the MIB, and provide the assumptions, reasoning, and rationale used to develop that model.

Virtual Circuits This memo strongly recommends that connection-oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual rows, especially those which have considerable redundant information. Note, as a comparison, that connection-less sub-layers do not have conceptual rows for each remote address. There may, however, be circumstances under which it is appropriate for a virtual circuit of a connection- oriented sub-layer to have its own conceptual row in the ifTable; an example of this might be PPP over an X.

The MIB in section 6 of this memo supports such circumstances. If a media-specific MIB wishes to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for this decision in the media-specific MIB's specification.

Bit, Character, and Fixed-Length Interfaces About half the objects in the ifTable are applicable to every type of interface: packet-oriented, character-oriented, and bit-oriented. Of the other half, two are applicable to both character-oriented and packet-oriented interfaces, and the rest are applicable only to packet-oriented interfaces. This is highly undesirable since it would require changes in every agent implementing the ifTable i. The solution adopted in this memo builds upon the fact that compliance statements in SNMPv2 in contrast to SNMPv1 refer to object groups, where object groups are explicitly defined by listing the objects they contain.

Thus, in SNMPv2, multiple compliance statements can be specified, one for all interfaces and additional ones for specific types of interfaces. The separate compliance statements can be based on separate object groups, where the object group for all interfaces can contain only those objects from the ifTable which are appropriate for every type of interfaces.

Using this solution, every sub-layer can have its own conceptual row in the ifTable. In addition, this memo defines several object groups for the purposes of defining which objects apply to which types of interface: 1 the ifGeneralGroup. This group contains those objects applicable to all types of network interfaces, including bit-oriented interfaces.

This group contains those objects applicable to packet-oriented network interfaces. As well as the octet counters, there are also a few other counters e. To accommodate this, the definitions of these counters are generalized to apply to character-oriented interfaces and fixed-length-transmission interfaces.

Counter Size Two approaches to addressing the shrinking minimum counter-wrap time problem were evaluated. Counters could be scaled, for example, ifInOctets could be changed to count received octets in, e. Alternatively, the size of the counter could be increased. Scaling the counters was rejected. While it provides acceptable performance at high count rates, at low rates it suffers.

If there is little traffic on an interface, there might be a significant interval before enough counts occur to cause a counter to be incremented. Traffic would then appear to be very bursty, leading to incorrect conclusions of the network's performance.

The alternative, which this memo adopts, is to provide expanded, 64 bit, counters. These counters are provided in new "high capacity" groups, The old, bit, counters have not been deprecated.

The bit counters are to be used only when the bit counters do not provide enough capacity; that is, the 32 bit counters could wrap too fast. For interfaces that operate at 20,, 20 million bits per second or less, bit byte and packet counters MUST be used.

These speed steps were chosen as reasonable compromises based on the following: 1 The cost of maintaining bit counters is relatively high, so minimizing the number of agents which must support them is desirable. Common interfaces such as Ethernet should not require them. It is reasonable to expect that support for them will be spotty for the immediate future.

Thus, we wish to limit them to as few systems as possible. This, in effect, means that bit counters should be limited to higher speed interfaces. Ethernet 10,, bps and Token Ring 16,, bps are fairly wide-spread so it seems reasonable to not require bit counters for these interfaces. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. The syntax of an object type defines the abstract data structure corresponding to that object type.

The ASN. 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. 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 ].

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 MIB-II March 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. 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.

This criterion reflects the fact that the current management protocols are not sufficiently secure to do more powerful control operations.

The general guideline was one counter per critical section per layer. There is no need to allow individual objects to be optional. 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. For many -- types of media, this will be in a binary representation.

If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software.

This value is allocated within the SMI enterprises subtree 1. By convention, this is the node's fully-qualified domain name. 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. Note that in the context of the Internet suite of protocols, values should be calculated accordingly: layer functionality 1 physical e.

The number of entries is given by the value of ifNumber. Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization. This string should include the name of the manufacturer, the product name and the version of the hardware interface. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The testing 3 state indicates that no operational packets can be passed. If the current state was entered prior to the last re- initialization of the local network management subsystem, then this object contains a zero value. One possible reason for discarding such a packet could be to free up buffer space.

For example, if the interface is realized by an ethernet, then the value of this object refers to a document defining objects specific to ethernet. From MIB-II and -- onwards, each network protocol group contains its own -- address translation tables.

Some interfaces do not use translation tables for determining address equivalences e. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex. Setting this object to a null string one of zero length has the effect of invaliding the corresponding entry in the atTable object.

That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atPhysAddress object.

IP gateways forward datagrams. IP hosts do not except those source-routed via the host. Note that for some managed nodes, this object may take on only a subset of the values possible.

This count includes invalid addresses e. For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address. In entities which do not act as IP Gateways, this counter will include only those packets which were Source-Routed via this entity, and the Source- Route option processing was successful.

Note that this counter does not include any datagrams discarded while awaiting re-assembly. Note that this counter does not include any datagrams counted in ipForwDatagrams. Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this discretionary discard criterion. Note that this includes any datagarms which a host cannot route because all of its default gateways are down.

Note that this is not necessarily a count of discarded IP fragments since some algorithms notably the algorithm in RFC can lose track of the number of fragments by combining them as they are received. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0.

For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this logical interface. An entry with a value of 0. Multiple routes to a single destination can appear in the table, but access to such multiple entries is dependent on the table- access mechanisms defined by the network management protocol in use.

The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to In the case of a route bound to an interface which is realized via a broadcast media, the value of this field is the agent's IP address on that interface. Note that the values direct 3 and indirect 4 refer to the notion of direct and indirect routing in the IP architecture.

Setting this object to the value invalid 2 has the effect of invalidating the corresponding entry in the ipRouteTable object. That is, it effectively dissasociates the destination identified with said entry from the route identified with said entry. Proper interpretation of such entries requires examination of the relevant ipRouteType object.

Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipRouteMask by determining whether the value of the correspondent ipRouteDest field belong to a class-A, B, or C network, and then using one of: mask network It should be noted that all IP routing subsystems implicitly use this mechanism.

Some interfaces do not -- use translation tables for determining address -- equivalences e. Setting this object to the value invalid 2 has the effect of invalidating the corresponding entry in the ipNetToMediaTable.

Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object. Note that this counter includes all those counted by icmpInErrors.