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)
<draft-tackabury-neo-mib-00.txt>
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]