Physical Topology (ptopo) Working Group Wayne F. Tackabury Internet-Draft Netsuite Development Expires in six months January 24, 1997 Network Element Object MIB (Neo-MIB) 1. Status of this Memo This document is a submission to the IETF Physical Toplogy (ptopo) Working Group. Comments are solicited and should be addressed to the working group mailing list (ptopo@3com.com) or to the author. This document in an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other working groups may also distribute their working documents as Internet Drafts. Internet Draft documents are valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them as other than "work-in-progress". To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Table of Contents 1. Status of this Memo 1 2. Abstract 2 3. Introduction 3 3.1 The SNMP Management Framework 3 3.2 The Neo-MIB 3 4. Background and Concepts 4 4.1 Agent Model Types 4 4.2 Segments 5 4.3 Connection Points 5 5. Requirements 5 5.1 Relationship to other MIBs 5 5.2 Support of Navigability 6 5.3 Extensibility between System and Service Agents 6 6. MIB Structure 6 6.1 Agent-level Data 6 6.2 ElementObject table 7 6.3 Segment table 7 6.4 Connection Points 7 6.4.1 Interfaces 8 6.4.2 Connection Nexuses 9 Tackabury [Page 1] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 6.4.3 Connections 9 6.5 Host table 9 6.6 Adapter table 10 7. Network Element Object MIB (neoMIB) 11 8. Security Considerations 27 9. Open Issues 27 10. Acknowledgements 28 11. Bibliography 28 12. Author's Address 28 2. Abstract This memo defines an experimental portion of the scope of the Management Information Base (MIB) for use with Internet community network management protocols. The particular focus of this MIB scope extension is the presentation and management of objects for network topology information. Constructs and encodings for these topology objects has been specified in a manner consistent with the dictates of the SNMP Version 2 SMI. 3. Introduction 3.1 The SNMP Management Framework The network managment framework of the Internet community is the Simple Network Management Protocol Version 2. Information for transfer through the SNMP [2] concern managed objects. These managed objects are accessed through a virtual information store, referred to as a Management Information Base (MIB). Managed objects in this MIB are encoded using a subset of ASN.1, identified in the SNMPv2 Structure of Managed Information [1], or SMI. Each such object type and its attributes are defined using an OBJECT-IDENTIFIER macro, as defined in the SMI. Each such managed object type is placed within the administrative scope of a subset of the ASN.1-encoded hierarchy defined within the SMI. An object type's OBJECT-IDENTIFIER macro definition references that placement. The OBJECT-IDENTIER macro for an object type also supplies a name associated with the object type. For purposes of symbolic and linguistic reference, this name is used to reference the object type notationally. An SNMP MIB agent is a process which provides access to instances of MIB object types by linking the object type data with its instance value. SNMP protocol operations are used to associate different access types varying in access level and granularity with the instance data provided in the protocol data units (PDU's) embodying those protocol operations. 3.2 The Neo-MIB The Network Element Object MIB (NeoMIB) is a portion of the SNMP MIB which defines an organization of objects acting as members of a connected network topology, and provides a means for an agent implementing the NeoMIB to represent data about such topological member elements. Tackabury [Page 2] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 The MIB serves only as a means to express the relationships and internal and external attributes of those data, and not to define or constrain means of collecting this relationship and attribute data. It is also important to note that the NeoMIB, unlike other MIBs commonly deployed throughout the Internet community, concerns itself with management of topology and not with the management of manageable elements of that topology. There is no direct operational linkage between the NeoMIB and management capabilities (or constraints thereupon) of the agents, or their managed elements, unlike the operational access provided by, for example, the Interfaces MIB [4], or the writable object types of MIB-II [5]. This provides an important limitation in the exposure to operational security considerations a NeoMIB agent would otherwise pose. 4. Background and Concepts The NeoMIB refers to a number of concepts and constructs which should be defined at the outset, to differentiate the usage of names associated with them from their, in some cases subtly, different usage in other MIBs and Internet documents. 4.1 Agent Model Types A variety of MIBs and elemental organization schemes underlying them have been proposed out of the current work of the IETF ptopo Working Group. One of the key differentiators has been the presumptions of the role of the agent in the way the MIB is deployed. We will use the term Topology MIB to generically describe a type of MIB to manage topology data (of which, of course, the NeoMIB is one). A Topology MIB which assumes a System Agent model for its agent implementation plays the role of a conventional MIB agent without proxy scope or capability. It represents only those elements which are nodally local to the agent process. To present an interconnected topology, a management application would have to query across some interconnected scope for presence of individual agents, and do a set of SNMP retrieval operations on each to collect the local topology data for each agent node. The management application must then, presumably with some connection context information present in the MIB data available from each agent, assemble a collected view of the topology on each. A clear benefit here in the interests of simplified agent implementation is the lack of any requirement for an explicit external (relative to the agent chassis) discovery protocol (although one could conceive of the usability for one in such an agent model, and in fact the primary proposal for a MIB which presumes this Agent Model does have features which leverage such an ability). The other agent model has been called a Server Agent. This does act in the role of a "proxy" for topological members represented by such a single agent within a given scope. A number of nodes, connections, and so forth have data available on them from a single agent which is construed as authoritative for that scope. For purposes of redundancy and possible convergence across agents of any underlying discovery protocol, there may be redundancy; management of that redundancy is an incumbent requirement on any underlying discovery protocol intended to be employed by such an agent or its discovery process. Of course, static configuration of topology data is also a viable underlying means of populating topology data to be exposed through the MIB agent; as Tackabury [Page 3] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 mentioned previously, it is not a dictate of the MIB specification that any particular means of discovery or such data population be employed or precluded as long as it provides directly or in combination with other means enough data for an agent to represent minimum conformance groups of the MIB. Nevertheless, a Server Agent implies richer minimum capabilities for whatever that method constitutes. On the other hand, this places a complete presentation control for a topology subset at the single point of control of that agent. Also, this provides a data model which extends effortlessly to deployment in an agent-manager mixed implementation (since distributed topology subsets can be collected for agent exposure at a "superagent" higher in the conceptual management structure). The primary reason why a System Agent model vs. a Server Agent model doesn't just represent a smooth continuum of scope is the fact that a Server Agent MIB must present some construct for containment of its topological scope (at a minimum; using this or other containment constructs for further topological segmentation within the data presented is also an option). This is not to say that a hybrid implementation is not possible. The NeoMIB is such a server-based and system-based agent. Capability for a server-based implmentation has been provided to leverage the distribution possibilities described above. However, there is a relative complexity of Server-based Topology MIB agent which does not lend such agents to being deployed on nodes which lack sufficient processing power and related resources (process space RAM, secondary virtual store, etc.) for such complexity. With such nonuniform deployment, by defintion, the capability for connected System Agents to represent a collected complete topology accurately is diminished. Hence, capability exists to have a NeoMIB agent "declare" itself as system-based, and foregoing exposing containment of the chassis-level representation it contains in its NeoMIB instance data. 4.2 Segments The unit of containment as present in the NeoMIB operating as a Server Agent is a Segment. A segment contains both connectable entities (in the topological sense), and potentially other segments if there is any nesting implied. An essential specific property of segments (where they are used) is the segment boundary type. This provides an advisory to the management application which can interpret boundary types as to the nature of the segment bounding interfaces in terms of passiveness and reachability of traffic, in addition to providing an advisory attribute which can be mapped to segment display characteristics in the typical topological map. Bounding points for the purposes of this discussion are transit points from one segment to another (assuming such adjacent segments are present--there is no technical reason why an adjacent segment must be present to nevertheless dictate a boundary of a given segment). Hence, boundary types include such options as routed, and passthrough (the latter, for example, presumably appropriate for a segment which is bounded by a layer 2 hub). They correspond with the predominant behavior of the ports which act as gateways from a segment to another segment (if present), as it relates conceptually to the flow of network traffic from that segment to the other segment. Tackabury [Page 4] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 Like many other such constructs in the NeoMIB, the specific usage and exact meaning of bounding types for instances for segment objects are at the discretion of the agent--it is not the role of the MIB to provide a didactic guideline as to what constitutes the difference between "switched" and "bridged" in the case of traversal from segment to segment over a port which displays characteristics of both--but agent implementors are guided to adhere to canonical definitions of the meaning of such terms as they apply to their well-known placement in network literature and products. 4.3 Connection Points The NeoMIB expands on the traditional notion of the "port" or "interface" as being, among other essential things, the receptacles of all connections between elements in a topology. For reasons of consistency in modeling and navigation through a topology, such an interface is grouped with another construct, the connection nexus (see section 6.4) to assemble an arbitrary construct called a Connection Point. Connection Points are the start or terminus (depending on orientation, of course) of any traversable connection in the NeoMIB. Connection Points are codified as their own layer in the MIB to aggregate the common characteristics and serve as a "container type" for those topological elements (interfaces, connection nexes) which they comprise. 5. Requirements The following requirements are construed as essential in the development of the NeoMIB. 5.1 Relationship to other MIBs To avoid redundancy of information, and to as well avoid competition of means of modeling characteristics and attributes of underlying physical topological elements, the ptopo group has agreed to strive to defer to the support for representation on those characteristics and attributes in agents supporting prior Draft Standard MIBs wherever possible. This has particular applicability to the elemental detail provided by the core MIB-II [5] and Entity MIB [3] agents supported on any represented agent node in the topology. The detail and relationships depicted by these agents' data should not be supplanted or duplicated by any object type specified in the NeoMIB. For a Server Agent NeoMIB agent implementation, this involves maintaining the presence of an external reference corresponding to a given element (interface, adapter) to indices within applicable tables in agents running on topology nodes which contain those elements. This, however, leads to a characteristic synchronization problem currently (see section 9), which is why some level of visibility of those elements must be provided by the NeoMIB agent topology representation itself. In short, there is no way to assure accuracy of, for example, a entityPhysicalIndex corresponding to a row which represents an adapter card on the target agent instance of the Entity MIB, as reflected in the reference of that index provided by the NeoMIB Server Agent's neoMibAdapterTable neoAdapterExtIndex instance, since the actual agent on the target node could have experienced power cycle or other cause for reindexing of these Entity MIB rows since the last time of target agent poll by the neoMIB agent. Tackabury [Page 5] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 5.2 Support of Navigability A major purpose of a Server Agent approach is to present cross-topological physical navigability from a single point of orientation (the Server Agent and its view of a segment). In general, support for a management station's ability to assembled a connection matrix as a function of analyzing a topology is an incumbent requirement for any Topology MIB (this term is being used here generically) which is going to represent a topology usefully. The NeoMIB is designed to present negligible impediments to assembling an enterprise-wide topology, which might otherwise be encountered as a weakness of the containment model, or weakness in the connection model itself. To the latter point, a word should be said about one of the motivations for the connection nexus notion. Where a connection is modeled as strictly point- to-point between physical interface or other single-receptacle Connection Points (to use our own term), several limitations arise in representing complex topologies. One is the fact that some physical or logical network attachment points are in fact multidrop, and means of modeling this using simplex connection constructs lead to anatomical deficiencies in the represented network. If no other construct is available to remedy this condition, a deviation, and in some cases a marked deviation, from the underlying physical topology must be presented by the Topology MIB agent. 5.3 Extensibility between System and Service Agents Finally, despite the fact that a NeoMIB agent is at its most useful and efficient (from the point of view of a management application) mode of deployment as a Server Agent, reasons discussed previously stand as to why this is a less-than-useful minimum ante for agent conformance. A group of System Agents implemented within a subnetwork must be able to provide a reconcilable, navigable (see 5.2) represented image of a topology, which, while lacking some of the details of containment and requiring some extra work on the part of the management application to collectively assemble same, should not preclude or limit this provision. 6. MIB Structure 6.1 Agent-level Data At the global scope of the agent, a number of attributes regarding agent operation and implementation are provided. Consistent with the discussion of a management application's being able to work with either a System or Server Agent, an indicator is given as to the model of an agent instance. A timestamp is provided to allow a management application to easily detect if a modification has been made which would suggest a need to repoll other parts of the agent data to look for new, deleted, or modified data. Finally, an advisory table which lists discovery mechanisms by autonomous type is given. This is strictly advisory, and agents which do not support discovery mechanisms which are tagged to a locus in a standard, experimental or proprietary administrative scope need not present any row data in the neoAgentDiscoveryMechanismTable. Tackabury [Page 6] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 6.2 ElementObject table The neoMibElementObjectTable has a row for every element in the topology. Entries in all element type-specific tables discussed below (neoMibSegmentTable, neoMibHostTable) have a corresponding row entry in this table as well. The neoMibSegmentEntry has fields which aggregate all common properties of these type-specific table entries. Examples of such attributes are type itself, display string, creation time (within the MIB instance data), etc. Perhaps the most important is the neoMibElementIndex, which acts as a primary reference index throughout references elsewhere in the MIB. 6.3 Segment table Segment-level table entries, which per the preceding discussion acts to "augment" the underlying segment object's identity as depicted in a neoMibElementObjectTable row, need to present fields to orient the segment as a container element, and potentially as a contained element as well (since segments can be arbitrarily "nested" within other segments). Additionally, rows in the neoMibSegmentTable have a field, neoSegmentLastModified, which acts as a container-level "last time modified" timestamp. This timestamp is to be updated when any of the elements in the segment (or more correctly, any of the interfaces in the segments or the host, connection, or adapter elements which reference those interfaces--see 6.4.1) have any of their instance data modified. This allows a management application to do poll for topology modifications as follows. neoAgentLastModified can be polled at the top level of the MIB, awaiting a change from a reference value (management application's last modified reference time). Upon detecting a change in neoAgentLastModified, the management application can do SNMP protocol operations to enumerate all segments' neoSegmentLastModified values, collecting all such values in excess of the management application's retained previous neoAgentLastModified value for the agent. The collection of segments with their neoSegmentLastModified in excess of this retained reference value represent the set of segments suitable for segment-ordered reenumeration of contained prior known elements to update what is at that point presumably an out-of-date (or nonexistent) segment element set on the management application. It should be noted that in the case of a System Agent implementation, or Server Agent representations of logically "flat" topologies, there may be no segmentation either available or called for. In these cases, all interfaces will have no containing segment references (neoInterfaceParentSegment = 0 for their neoMibInterfaceTable rows), and there will be no entries in the neoMibSegmentTable. 6.4 Connection Points Connection Points simply represent, currently, one point in the MIB hierarchy. Connection nexuses and Interfaces are the subcontained groups for this level. Connection Points combine all connectable entities. As it turns out, there are currently no attributes for reindexing and aggregation in some neoMibConnectionPointTable, so one is not defined. Tackabury [Page 7] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 Since Connection Points embody all of the fundamental navigable units within the NeoMIB, the motivation for maintaining this point in the hierarchy is navigational within the MIB. An efficient algorithm for initial scan by a NeoMIB-aware management application of a NeoMIB topology using SNMP GET protocol operations would proceed by enumerating entirely through the neoMibCnxnPoint scope, picking up all of its contained object type instances and their attributes in associated table row entries. In this way, the most elemental "building blocks" from the point of view of connection creation and connection reference integrity are present as those connections (and other referencing elements such as hosts, adapters, and segments) reference these connection points. 6.4.1 Interfaces Hence, interfaces are a conceptual "subtype" of the connection point. The NeoMibInterfaceEntry is the richest aggregate object type in the MIB. The fields here need to be sufficient for placement within the topology, for behavior within the segment, and to additionally provide enough context information to allow direct access to the management agent on which this interface physically resides in the network. To satisfy this requirement, the NeoMibInterfaceEntry has references to the "parenting" segment, host, and adapter by each such "parenting" element's neoMibElementIndex value. Agent implementors are encouraged to ensure association to a neoMibHostTable via a value in the NeoMibInterfaceEntry neoInterfaceParentHost field to allow a management application to have a predictable display mechanism for interfaces (i.e., attached to a host topology object). However, lack of association to a neoMibAdapterTable entry is perfectly acceptable when lack of adapter-level detail is available through the discovery mechanism or when an interface is construed to be "motherboard- based" or in some other way not placed on an expansion adapter. The neoInterfacePrimaryAddrDomain and neoInterfacePrimaryAddress provide agent addressing data for this interface's controlling management agent. The neoInterfaceIsSegmentBoundary defines whether this interface corresponds to a boundary in the parent segment. Since the neoMibSegmentTable entry indexed by an interface's neoInterfaceParentSegment type has a field in its own right, neoSegmentBoundaryType, defining the presumed traversability of this interface in its function as a segment boundary interface, these two characteristics (the interface's segment boundary role and its role as a type of interface of neoSegmentBoundaryType) conceptually are linked. The relative complexity of this determination is what causes us to formally decouple this role as a segment boundary from its role in general, as reflected in the neoInterfacePortBehavior of a neoMibInterfaceTable entry. All interfaces (regardless of the value of neoInterfaceIsSegmentBoundary) can represent a "port behavior" through this field. Port behaviors are cumulative, using the same mechanism that sysServices in [4] employs to combine multiple values. The values available here are designed to provide a flexible indicator as to the layer at which traffic can be processed into and across the interface. This allows a management application to make determinations on display characteristics for an interface's host in a display based on supported services, in addition to determinations on base reachability of one interface to another under varying conditions of payload type and size, presumed delay, etc. Tackabury [Page 8] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 6.4.2 Connection Nexuses A connection nexus is in some respects a basic Connection Point as it has been defined in 6.4. Since it does not represent a physical entity, it can be used to aggregate connections to a logical entity, such as a WAN Service Provider, which may conceptually reside in the middle of a topology. It may also be used to represent a physical aggregation of connection (such as a multidrop bus connection point in LAN wiring). Its lightweight minimal attribute exposure in its neoMibCnxnNexusTable row instance provides one primary enabling feature--an easy way to associate multiple connection objects to a given connection nexus by reference. A connection nexus is intended to be used in any situation in the modeling of the topology where multiple connections originating from one logical or physical place are required. While there is no way to specifically prevent it currently, it is NOT intended that multiple neoMibConnectionTable entries reference the same neoMibInterfaceTable entry, and agent implementors SHOULD NOT allow this condition to occur, so as to allow the management application to have a predictable connected topological element set to handle for display and layout purposes. A Connection Nexus does reference a segment through its neoMibCnxnNexusTable row instance neoCnxnNexusParentSegment value, but is notably NOT capable of specifying itself as a boundary to that segment. This is since it would not be possible in this architecture to determine where internally to the connection nexus the segment is split on. Secondarily, initial implementation experience has shown that the usefulness of specifying a connection nexus point as a segment boundary is negligible. 6.4.3 Connections Consistent with the preceding description of Connection Point-derived elements, a connection is simply a table entry with two references, each to some such Connection Point-scoped topology element. As stated earlier, while there is no way to specifically prevent it currently, it is NOT intended that multiple neoMibConnectionTable entries reference the same neoMibInterfaceTable entry, and agent implementors SHOULD NOT allow this condition to occur. An unlimited number of neoMibConnectionTable entries CAN reference the same neoMibCnxnNexusTable row entry, however. Finally, agent implementors SHOULD NOT allow a condition to have the neoConnectionEP1 field and neoConnectionEP2 field of the same neoMibConnectionTable entry reference the same neoMibCnxnNexusTable or neoMibInterfaceTable entry under any condition. 6.5 Host table Node-level entities are represented by rows in the neoMibHostTable. The only field supported in a row instance of this table provides a neoHostSysObjectId which differs from the MIB-II sysObjectID in that it does not need to be directly coupled to the management subsystem. Tackabury [Page 9] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 6.6 Adapter table Adapter-level detail, where available through a discovery mechanism employed by a neoMIB agent's discovery process, is represented through rows in the neoMibAdapterTable. A row in this table contains the same kind of object administrative reference in its neoAdapterSysObjectId that is has been described for the neoHostSysObjectId. Additionally, a reference is contained to the encountered entPhysicalIndex of the entPhysicalIndex in the Entity MIB entPhysicalTable which is either in the local Entity MIB agent data (in the case of a Server or System Agent's neoMibAdapterTable corresponding to an adapter on the same chassis that the neoMIB agent is running on), or which was encountered by a Server Agent NeoMIB from the agent on the node on which this adapter physically resides in the network. This reference is the neoMibAdapterExtEntityIndex field of the neoMibAdapterTable. Where this index is nonzero and hence to be construed as valid, several conditions should be able to be assumed by a management application. One is that the neoMibAdapterExtEntityIndex was valid (was a valid entPhysicalIndex in the applicable Entity MIB agent data) at the TimeStamp marked at the neoMibElementCheckpointTime field for the neoMibElementObjectTable row entry with the same neoMibElementIndex value as this neoMibAdapterTable entry has. Another is that as a byproduct of that validity of association, the entPhysicalClass value in the entPhysicalTable row with this neoMibAdapterExtEntityIndex in this Entity MIB agent data had a PhysicalClass value of `container (5)' at that neoMibElementCheckpointTime time of last encounter. Where available, this Entity MIB reference is necessary to properly qualify the placement of adapter cards relative to each other, for example, which are primarily connected to a system bus and which are in turn daughter-cards to each other. As far as the neoMibAdapterTable is concerned, these are simply entries at a peer level with no indicator present from the neoMIB agent data to represent this kind of placement information. Tackabury [Page 10] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 7. Network Element Object MIB (neoMIB) NEO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental FROM SNMPv2SMI TEXTUAL-CONVENTION, TDomain, TAddress, DisplayString, RowPointer, TimeStamp, DateAndTime, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; neoMib MODULE-IDENTITY LAST-UPDATED "9612260000Z" ORGANIZATION "IETF Physical Topology Working Group" CONTACT-INFO " WG E-mail: ptopo@3Com.com Subscribe: ptopo-request@3com.com Ken Jones ptopo Working Group Chair Bay Networks, Inc. 4401 Great America Parkway PO Box 58185, MS SC01-04 Santa Clara, CA 95052-8185 kjones@baynetworks.com Wayne F. Tackabury NeoMIB Document Author Netsuite Development, L.P. 321 Commonwealth Rd., Ste. 300 Wayland, MA 01778 Tel: (508) 647-3114 waynet@netsuite.com" DESCRIPTION "The MIB module for representing a topology of one or more chassis-level network elements, with connections from logical connection point network elements to other connection point network elements on other chassis. The agent supporting an instance of this MIB can be representing only the chassis on which the agent resides and optionally its attached connections and other subelements, or can be representing a group of such chassis-level systems and sublements, optionally with each of their connections represented as well. The former is known as a topology system agent, the latter is known as a topology service agent." ::= {experimental 666} -- replace with IANA ptopo assignment neoMibObjects OBJECT IDENTIFIER ::= { neoMib 1 } Tackabury [Page 11] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 -- Groups within neoMIB neoMibAgent OBJECT IDENTIFIER ::= { neoMibObjects 1 } neoMibElementObject OBJECT IDENTIFIER ::= { neoMibObjects 2 } neoMibSegment OBJECT IDENTIFIER ::= { neoMibObjects 3 } neoMibHost OBJECT IDENTIFIER ::= { neoMibObjects 4 } neoMibCnxnPoint OBJECT IDENTIFIER ::= { neoMibObjects 5 } neoMibInterface OBJECT IDENTIFIER ::= { neoMibCnxnPoint 1 } neoMibCnxnNexus OBJECT IDENTIFIER ::= { neoMibCnxnPoint 2 } neoMibConnection OBJECT IDENTIFIER ::= { neoMibObjects 6 } neoMibAdapter OBJECT IDENTIFIER ::= {neoMibObjects 7} -- Textual conventions used throughout neoMIB NeoIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Integer index used to reference network element objects back to their primary containing table." SYNTAX INTEGER (0..2147483647) NeoNodalType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Type of neoMib element instance. This allows a mapping from container types (neoElementObject, neoCnxnPoint) to actual types of element objects as represented by an entry in neoMibSegmentTable, neoMibInterfaceTable etc. (in this example, neoSegment, neoInterface respectively)." SYNTAX INTEGER { other(1), -- in what table would "other" show up? neoSegment(2), neoHost (3), neoInterface(4), neoCnxnNexus(5), neoAdapter(6) } -- neoMibAgent section. -- this contains nodal entries for data describing this agent's -- configured role and current agent status. neoAgentType OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), topoSystemAgent(3), topoServiceAgent(4) } MAX-ACCESS read-only STATUS current Tackabury [Page 12] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 DESCRIPTION "The type of this agent. Among defined types, a topoSystemAgent only represents the logical chassis on which the agent resides, along with any known connected partners. A topoServiceAgent corresponds with a topology server implementation, where a community of nodes is being represented (along with any known connections amongst their connectionPoints) by this agent." ::= { neoMibAgent 1 } neoAgentLastModified OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time of last modification of any of the topological data available from this server. More specifically, the last time that any adds, removes, changes in value or linkage of any of the row entries in the neoMibElementObjectTable occurred relative to sysUpTime. A management application can monitor this object to determine appropriate points to re-query the rows of the neoMibElementObjectTable and its higher level tables for updates." ::= { neoMibAgent 2 } neoAgentOperState OBJECT-TYPE SYNTAX INTEGER { other (1), unknown (2), startup (3), collecting (4), -- in dyanmic/other data collection idle (5), -- idle/processing agent requests shutdown(6), error-state (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current overall operational state of this neoMIB agent process. This is intended to be a rough approximation of current state as suitable for a management application's choice of graphical indicators of this agent and to guide other choice of agent selection and diagnostics." ::= { neoMibAgent 3} neoAgentDiscoveryMechanismTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoAgentDiscoveryMechanismEntry MAX-ACCESS not-accessible STATUS current Tackabury [Page 13] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 DESCRIPTION "This table contains one row for each marked mechanism or algorithm of discovery as used for discovery of at least one connectionPoint as represented by a row in the neoMibElementObjectTable." ::= { neoMibAgent 4 } neoAgentDiscoveryMechanismEntry OBJECT-TYPE SYNTAX NeoAgentDiscoveryMechanismEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a mechanism or algorithm of discovery as used for discovery of at least one connectionPoint as represented by a row in the neoMibElementObjectTable." INDEX { neoAgentDiscoveryMechanismIndex } ::= { neoAgentDiscoveryMechanismTable 1 } NeoAgentDiscoveryMechanismEntry ::= SEQUENCE { neoAgentDiscoveryMechanismIndex NeoIndex, neoAgentDiscoveryMechanismIdentifier AutonomousType } neoAgentDiscoveryMechanismIndex OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for this discovery mechanism entry." ::= { neoAgentDiscoveryMechanismEntry 1 } neoAgentDiscoveryMechanismIdentifier OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "Identifier of a vendor-specific or other registered discovery type, heuristic, or algorithm. The value { 0 0 } (a NULL object identifier) indicates static or other unidentified discovery means. Otherwise, each row denotes a discovery mechanism outside of the administrative scope of this MIB (for example, within a vendor scope). " ::= { neoAgentDiscoveryMechanismEntry 2 } -- neoMIBElementObject section. Rows of the table contained herein -- describe all MIB object instances which will be present in other -- tables specific to the instance type (neoMIBSegmentTable, -- neoMIBInterfaceTable, etc.), and will decribe properties and -- attributes of all such objects. neoMibElementObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibElementEntry MAX-ACCESS not-accessible STATUS current Tackabury [Page 14] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 DESCRIPTION "This table contains one row of every object, regardless of object nodal type, about which this agent is aware and capable of delivering data." ::= { neoMibElementObject 1 } neoMibElementEntry OBJECT-TYPE SYNTAX NeoMibElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single neoMib object." INDEX { neoMibElementIndex } ::= { neoMibElementObjectTable } NeoMibElementEntry ::= SEQUENCE { neoMibElementIndex NeoIndex, neoMibElementType NeoNodalType, neoMibElementDescription DisplayString, neoMibElementCreationTime DateAndTime, neoMibElementCheckpointTime TimeStamp, neoMibElementRowStatus RowStatus } neoMibElementIndex OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of this element within this base element object table. This index permeates through to references in other tables pertinent to the nodal type of this object." ::= { neoMibElementEntry 1 } neoMibElementType OBJECT-TYPE SYNTAX NeoNodalType MAX-ACCESS read-only STATUS current DESCRIPTION "Nodal type of this element. All elements ultimately resolve to a nodal type denoting their role in the topology represented by this MIB instance. Such role is reflected for the element of this row by the value of its neoMibElementType." ::= { neoMibElementEntry 2 } neoMibElementDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A text string describing this element. No presumptions are made about the contents or requirement of this informational string, and it may very well be a null DisplayString." ::= { neoMibElementEntry 3 } Tackabury [Page 15] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 neoMibElementCreationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Historic creation date of this object in this topology. If this object was entered statically or is otherwise a part of a topology which was created in a prior operational cycle of this agent, then this time may precede the time of sysUp for this agent." ::= { neoMibElementEntry 4 } neoMibElementCheckpointTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Time, relative to sysUpTime, that this element was last last affirmatively encountered by the agent. A TimeStamp value of zero indicates that this element has not been encountered and verified by the agent process within this operational cycle of this agent. Note that such a zero value is not to be construed as an indication of actual element (e.g., network node) dysfunction or disappearance, since elements which were added to the neo Topology statically may never be checkpointed after their static addition to the topology base. Alternately, in a highly dynamic discovery agent methodology, guidelines for aging out of elements which have not been encountered in some max threshold are beyond the scope of this MIB." ::= { neoMibElementEntry 5 } neoMibElementRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibElementObjectTable." ::= { neoMibElementEntry 6 } -- neoMibSegment section. This contains top-level groupings of the -- network elements exposed by this agent as a function of their -- content and bounding operation within the network. Note in -- particular that a segment can contain another segment. neoMibSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row for every segment. Note that each segment will also have a row in the Tackabury [Page 16] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 neoMibElementObjectTable. An agent which wishes to express a topology image which contains only the agent chassis, its ports and known connections could forego supporting any retrieval capability for segment data, pursuant to its ConformanceGroup options." ::= { neoMibSegment 1 } neoMibSegmentEntry OBJECT-TYPE SYNTAX NeoMibSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single segment." INDEX { neoMibElementIndex } ::= { neoMibSegmentTable 1 } NeoMibSegmentEntry ::= SEQUENCE { neoSegmentLastModified TimeStamp, neoSegmentBoundaryType INTEGER, neoSegmentParentSegment NeoIndex, neoSegmentRowStatus RowStatus } neoSegmentLastModified OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "A timestamp, relative to sysUpTime, of last modification of this segment, any of its contained interfaces, hosts, or connection points. A management application can use this to efficiently determine sections of a topology exposed by this topology server which require update retrieval for synchronization with current topology state." ::= { neoMibSegmentEntry 1 } neoSegmentBoundaryType OBJECT-TYPE SYNTAX INTEGER { other (1), unknown (2), unbounded (3), routed (4), switched (5), bridged (6), passthrough (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication as to the nature of the boundary interfaces of this segment. This will allow a management or simulation application to make rough determinations as to reachability, layer 2 and 3 collision domains, and other properties Tackabury [Page 17] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 governing intersegment traffic flow. The value 'unbounded (3)' could be used for either a self-contained segment or segment physically not connected to any other, or for a dual-homed segment boundary node type where no traffic automatically flows from one segment to another without application-level intervention. The value 'bridged (6)' would pertain to an 802.1(d) or other formalized model (e.g., Token Ring MAU) of layer 2 bridge segment boundary interface. The value 'passthrough (7)' is used to denote, for example, a segment bounded by passive layer 2 ports such as a segment of devices connected through a 802.3 hub." ::= { neoMibSegmentEntry 2 } neoSegmentParentSegment OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The neoMibElementIndex of the segment which is logically considered to be the 'parent' of the segment denoted by this row instance. The semantics of 'parent' are under the control of the agent, but agent implementors are encouraged to use the implications of the values of neoSegmentBoundaryType in setting up parent relationships for segments. In all other respects, this allows the management application to display a logical and consistent view of containment of segment groupings of network elements. A neoSegmentParentSegment value of zero indicates that this segment is unparented, or is at the 'top level' of the segment containment scope." ::= { neoMibSegmentEntry 3 } neoSegmentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibSegmentTable." ::= { neoMibSegmentEntry 4 } -- NeoMibHost section. This section embodies the neoMib-pertinent -- data on chassis-level network elements. neoMibHostTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row for every host. While hosts can be individually retrieved through this table in coordination with their presence as base elements in the neoMibElementObjectTable, as a primary means of navigating through segment inclusion or element-to-element connection, a management application will probably want to first examine Tackabury [Page 18] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 the interfaces by segment or unsegmented indexing, and map to host-level interface containment from there." ::= { neoMibHost 1 } neoMibHostEntry OBJECT-TYPE SYNTAX NeoMibHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single host." INDEX { neoMibElementIndex } ::= { neoMibHostTable 1 } NeoMibHostEntry ::= SEQUENCE { neoHostSysObjectId AutonomousType, neoHostRowStatus RowStatus } neoHostSysObjectId OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "A vendor or other identification of chassis by management agent subsystem or other attribute of administrative scope implied by AutonomousType. Since this need not be tied specifically to management subsystem, this may or may not be the same as sysObjectID from RFC 1907. An object identifier of null, or {0 0} denotes no such identification attribute is present for this host." ::= { neoMibHostEntry 1 } neoHostRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibHostTable." ::= { neoMibHostEntry 2 } -- neoMibInterface section. This describes all attributes of interfaces, -- as connectable, addressable, and otherwise host-contained navigable -- endpoints of the collected network topology. The collection of -- interfaces under the hierarchical grouping neoMibCnxnPoint reflects -- the fact that they share a crucial common property with the other -- member of that hierarchical grouping (neoMibCnxnNexus) that they -- can be endpoints of a connection, that is, can be referenced by -- neoMibConnectionTable row entries. neoMibInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibInterfaceEntry MAX-ACCESS not-accessible STATUS current Tackabury [Page 19] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 DESCRIPTION "This table contains one row for every interface. Note that each interface will also have a row in the neoMibElementObjectTable. " ::= { neoMibInterface 1 } neoMibInterfaceEntry OBJECT-TYPE SYNTAX NeoMibInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single interface. This is primarily indexed by parent segment to accomodate easy per-segment table traversal by management application requests." INDEX { neoInterfaceParentSegment, neoMibElementIndex } ::= { neoMibInterfaceTable 1 } NeoMibInterfaceEntry ::= SEQUENCE { neoInterfaceParentSegment NeoIndex, neoInterfaceParentHost NeoIndex, neoInterfaceParentAdapter NeoIndex, neoInterfacePrimaryAddrDomain TDomain, neoInterfacePrimaryAddress TAddress, neoInterfaceExtIndex NeoIndex, neoInterfaceIsSegmentBoundary TruthValue, neoInterfacePortBehavior INTEGER, neoInterfaceRowStatus RowStatus } neoInterfaceParentSegment OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to the neoMibElementIndex of the segment containing this interface. A NeoIndex value of zero denotes a lack of containment to a segment, and is obviously the only allowable value in an unsegmented topology." ::= { neoMibInterfaceEntry 1 } neoInterfaceParentHost OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to the neoMibElementIndex of the host element containing this interface. A NeoIndex value of zero denotes a lack of containment to a host. Such a lack of containment is not recommended by agent implementations in any interface instance exported by this table with a neoInterfaceRowStatus value of 'ready' since such interfaces do not map readily to a rational means of display for querying management applications. Tackabury [Page 20] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 For interfaces whose row instances have a neoInterfaceParentHost nonzero value but a zero value for neoInterfaceParentAdapter, the interface can be construed to be 'embedded' or logically motherboard-attached on the parent host." ::= { neoMibInterfaceEntry 2 } neoInterfaceParentAdapter OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to the neoMibElementIndex of the adapter element containing this interface. A NeoIndex value of zero denotes a lack of containment to an adapter. Such a lack of containment where an interface row instance has a nonzero neoInterfaceParentHost value can be construed to denote an interface 'embedded' or logically motherboard-attached on the chassis referenced by neoInterfaceParentHost." ::= { neoMibInterfaceEntry 3 } neoInterfacePrimaryAddrDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Type of transport service for the primary transport address associated with the management subsystem of this interface. A TDomain value of {0 0} is allowable to denote lack of known or expressed management subsystem addressability from this row instance, provided that neoInterfacePrimaryAddress is also zero. Where nonzero, NOTE that this is not necessarily the same as the Tdomain for an address this interface is assuming in its network operation in the topology" ::= { neoMibInterfaceEntry 4 } neoInterfacePrimaryAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Primary transport address associated with the management agent subsystem of this interface, as governed by neoInterfacePrimaryAddrDomain. A null value of neoInterfacePrimaryAddress is allowable to denote lack of known or expressed mangement subsystem addressability from this row instance, provided that neoInterfacePrimaryAddrDomain is also zero. NOTE that this is not necessarily the same as the address this interface is assuming in its network operation in the topology." ::= { neoMibInterfaceEntry 5 } Tackabury [Page 21] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 neoInterfaceExtIndex OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Value of the ifIndex associated with the row of the ifTable in the MIB-II agent data for the agent last found at neoInterfacePrimaryAddress, where said ifTable row corresponds with this interface." ::= { neoMibInterfaceEntry 6 } neoInterfaceIsSegmentBoundary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this port represents a boundary with respect to its containing segment, if any. If the neoInterfaceParentSegment instance for this row is zero, then neoInterfaceIsSegmentBoundary should be set to a TruthValue value of 'false'. Otherwise, this value denotes whether this port is a boundary port in its segment, which is to say whether it represents a point of traversal into any colocated segments relative to the containing segment of this interface." ::= { neoMibInterfaceEntry 7 } neoInterfacePortBehavior OBJECT-TYPE SYNTAX INTEGER (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A set of network behaviors being exhibited in this topology by this interface. The value is a sum. This sum initially takes the value zero. Then, for each behavior, B, in the range 1 through 32, that this node performs servicesfor, 2 raised to (B - 1) is added to the sum. 1 = unknown 2 = other 3 = endnode (having 'layer 3' addressability) 4 = power backup (e.g., UPS) 5 = management agent (e.g., has SNMP agent) 6 = topology MIB management agent (presumes 'management agent') 7 = hub (passive) 8 = switch (LAN/WAN) 9 = route 10 = serial translation (e.g., modem, DSU) 11 = stream concentration (or active hub, e.g., FDDI) 12 = address translation (e.g., RFC1577 LIS) 13 = bridge (i.e., 802.1) 14 = electromechanical transceiver Tackabury [Page 22] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 Combination of these values are mutually exclusive and have no explicit limitation or provision on how they can be bound." ::= { neoMibInterfaceEntry 8 } neoInterfaceRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibInterfaceTable." ::= { neoMibInterfaceEntry 9 } -- neoMibCnxnNexus section. This describes relevant attributes -- of connection nexes, as simple topological containers for groups -- of logical endpoints of connections, which endpoints are not -- integrated into chassis elements, et al, such as interfaces are. -- Conceptually, interfaces are seen as being able to reference a -- single neoMibConnectionEntry per interface, where a connection -- nexus can be referenced by multiple neoMibConnectionEntries, -- since the notion of an "endpoint" of a connection nexus is never -- really formally exposed. Note that such an "endpoint" of a -- connection nexus can be connected to an interface, or to another -- connection nexus. neoMibCnxnNexusTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibCnxnNexusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row for every connection nexus. Note that each connection nexus will also have a row in the neoMibElementObjectTable. " ::= { neoMibCnxnNexus 1 } neoMibCnxnNexusEntry OBJECT-TYPE SYNTAX NeoMibCnxnNexusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single connection nexus." INDEX { neoMibElementIndex } ::= { neoMibCnxnNexusTable 1 } NeoMibCnxnNexusEntry ::= SEQUENCE { neoCnxnNexusParentSegment NeoIndex, neoCnxnNexusNumConnections INTEGER, neoCnxnNexusRowStatus RowStatus } Tackabury [Page 23] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 neoCnxnNexusParentSegment OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to the neoMibElementIndex of the segment containing this connection nexus. A NeoIndex value of zero denotes a lack of containment to a segment, and is obviously the only allowable value in an unsegmented topology." ::= { neoMibCnxnNexusEntry 1 } neoCnxnNexusNumConnections OBJECT-TYPE SYNTAX INTEGER (1..4096) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of current references to this connection nexus to be found amongst the rows of the neoMibConnectionTable. This is to facilitate ease of evaluating all connections to this connection domain from other neoMibCnxnPoints" ::= { neoMibCnxnNexusEntry 2 } neoCnxnNexusRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibCnxnNexusTable." ::= { neoMibCnxnNexusEntry 3 } -- neoMibConnection section. This section details all connections -- between network elements elsewhere derived from neoMibCnxnPoint. neoMibConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row for every connection. Note that each connection will also have a row in the neoMibElementObjectTable. " ::= { neoMibConnection 1 } neoMibConnectionEntry OBJECT-TYPE SYNTAX NeoMibConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single connection." INDEX { neoMibElementIndex } ::= { neoMibConnectionTable 1 } Tackabury [Page 24] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 NeoMibConnectionEntry ::= SEQUENCE { neoConnectionEP1 NeoIndex, neoConnectionEP2 NeoIndex, neoConnectionRowStatus RowStatus } neoConnectionEP1 OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "neoMibElementIndex of the neoMib element derived from neoMibCnxnPoint which comprises one end of this duplex connection. This should be an index to a valid row in the neoMibElementObjectTable, and should not be the same as the instance of neoConnectionEP2 in this row." ::= { neoMibConnectionEntry 1 } neoConnectionEP2 OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "neoMibElementIndex of the neoMib element derived from neoMibCnxnPoint which comprises one end of this duplex connection. This should be an index to a valid row in the neoMibElementObjectTable, and should not be the same as the instance of neoConnectionEP1 in this row." ::= { neoMibConnectionEntry 2 } neoCnxnNexusRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibConnectionTable." ::= { neoMibConnectionEntry 3 } -- Adapter section. neoMibAdapterTable OBJECT-TYPE SYNTAX SEQUENCE OF NeoMibAdapterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row for every adapter." ::= { neoMibAdapter 1 } neoMibAdapterEntry OBJECT-TYPE SYNTAX NeoMibAdapterEntry MAX-ACCESS not-accessible STATUS current Tackabury [Page 25] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 DESCRIPTION "Information about a single adapter." INDEX { neoMibElementIndex } ::= { neoMibAdapterTable 1 } NeoMibAdapterEntry ::= SEQUENCE { neoAdapterSysObjectId AutonomousType, neoAdapterExtIndex NeoIndex, neoAdapterRowStatus RowStatus } neoAdapterSysObjectId OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "A vendor or other identification of adapter by management agent subsystem or other attribute of administrative scope implied by AutonomousType. An object identifier of null, or {0 0} denotes no such identification attribute is present for this adapter." ::= { neoMibAdapterEntry 1 } neoAdapterExtIndex OBJECT-TYPE SYNTAX NeoIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Value of the entPhysicalIndex associated with the row of the entPhysicalTable in the Entity MIB agent data for the agent last found at the neoInterfacePrimaryAddress for any of the NeoMibInterfaceTable entries which reference this neoMibAdapterEntry neoMibElementIndex, where said entPhysicalTable row corresponds with this adapter." ::= { neoMibAdapterEntry 2 } neoAdapterRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Status of this row in the neoMibHostTable." ::= { neoMibAdapterEntry 3 } END Tackabury [Page 26] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 8. Security Considerations The neoMIB is intended to provide read access to data which has been collected through some discovery mechanism outside of the scope of the MIB. In its current form, creation or write access is not provided for any of its object types. Security implications of the availability on data of any of its represented topological elements is seen as the province of security considerations for individual discovery and population mechanisms, if at all. As a result, the deployment of the neoMIB is not seen as being relevant to any further security requirements or implications. 9. Open Issues (as of 15 January 1997) * I'm unclear as to whether there is a move afoot to preserve the integrity of the chassis MIB PhysicalIndex values as there has been for the ifIndex of recent. I'm under the impression that the consensus in the ifMIB group and others is to require implementors to not "reuse" ifIndices of interfaces which have gone away for some reason. Is the same true of Entity MIB indices? That would partially alleviate the "cross agent" synchronization problem of the NeoMIB latching another agent's index values in neoAdapterExtIndex and neoInterfaceExtIndex. More fundamentally, is this acceptable to people? I really don't know how we can have a Server Agent implementation AND preserve the primacy of the Entity MIB otherwise. * Considerations for interoperability of Server Agents and System Agents within the same Segment physical space need to be addressed. * There are general considerations for system agents as well which need exploring and potential elaboration in the document. How are "adjacent" nodes sorted out between adjacent neoMIB agents representing each other as connected neighbors? I'd say by some combination of mgmt. addr + ifIndex (aka neoInterfaceExtIndex), but do we need to provide guidelines for management application writers here? * Acceptability of a single segment bounding type? This is for simplicity sake, basically. * In general, should altorithms for MIB scope traversal (interfaces -> hosts -> segments, et al) be provided? There are a number of ways to do it, but none are "trivial" really. The discussion in sec. 4.2 on a segment-ordered MIB polling algorithm does not discuss removal of any "deleted" segments. Tackabury [Page 27] Internet-Draft draft-tackabury-neo-mib-00.txt January 24, 1997 10. Acknowledgements Gratitude is owed to Maria Greene (Ascom-Nexion) for helping to refine a number of ideas here and for keeping me from throwing some truly silly constructs in here. Prior contributions from Greene, Prakash Desai (Bay Networks) and H. Nikolaus Schaller (Lehrstuhl fure Datenverarbeitung) have been influential in the developmnent of the NeoMIB. Finally, my Netsuite colleagues Kevin Cronin, Dan Tonelli, and Lazarus Vekiarides have been instrumental in developing the conceptual underpinnings of what has become the NeoMIB. 11. Bibliography [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January, 1996 [3] McCloghrie, K, and Bierman, A., "Entity MIB using SMIv2", RFC 2037, October, 1996. [4] McCloghrie, K. and Kastenholtz, F., "Interfaces Group Evolution", RFC 1573, January 1994. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January, 1996. 12. Author's Address Wayne F. Tackabury Netsuite Development, L.P. 321 Commonwealth Rd., Ste. 300 Wayland, Massachusetts 01778 Phone: (508) 647-3114 Fax: (508) 647-3112 Email: waynet@netsuite.com Tackabury [Page 28]