[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]