idnits 2.17.1 draft-tackabury-neo-mib-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 26) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 378 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 447: '...e entry, and agent implementors SHOULD...' RFC 2119 keyword, line 468: '...ent implementors SHOULD NOT allow this...' RFC 2119 keyword, line 472: '...ent implementors SHOULD NOT allow a co...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 601 has weird spacing: '...ceTable etc. ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 1997) is 9954 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 1427 looks like a reference -- Missing reference section? '1' on line 1423 looks like a reference -- Missing reference section? '4' on line 1434 looks like a reference -- Missing reference section? '5' on line 1437 looks like a reference -- Missing reference section? '3' on line 1431 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Physical Topology (ptopo) Working Group Wayne F. Tackabury 3 Internet-Draft Netsuite Development 5 Expires in six months January 24, 1997 7 Network Element Object MIB (Neo-MIB) 8 10 1. Status of this Memo 12 This document is a submission to the IETF Physical Toplogy (ptopo) Working 13 Group. Comments are solicited and should be addressed to the working group 14 mailing list (ptopo@3com.com) or to the author. 16 This document in an Internet Draft. Internet Drafts are working documents of 17 the Internet Engineering Task Force (IETF), its areas, and its working groups. 18 Note that other working groups may also distribute their working documents as 19 Internet Drafts. 21 Internet Draft documents are valid for a maximum of six months, and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet Drafts as reference material or to cite them as 24 other than "work-in-progress". 26 To learn the current status of any Internet Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 32 Table of Contents 34 1. Status of this Memo 1 35 2. Abstract 2 36 3. Introduction 3 37 3.1 The SNMP Management Framework 3 38 3.2 The Neo-MIB 3 39 4. Background and Concepts 4 40 4.1 Agent Model Types 4 41 4.2 Segments 5 42 4.3 Connection Points 5 43 5. Requirements 5 44 5.1 Relationship to other MIBs 5 45 5.2 Support of Navigability 6 46 5.3 Extensibility between System and Service Agents 6 47 6. MIB Structure 6 48 6.1 Agent-level Data 6 49 6.2 ElementObject table 7 50 6.3 Segment table 7 51 6.4 Connection Points 7 52 6.4.1 Interfaces 8 53 6.4.2 Connection Nexuses 9 54 6.4.3 Connections 9 55 6.5 Host table 9 56 6.6 Adapter table 10 57 7. Network Element Object MIB (neoMIB) 11 58 8. Security Considerations 27 59 9. Open Issues 27 60 10. Acknowledgements 28 61 11. Bibliography 28 62 12. Author's Address 28 64 2. Abstract 66 This memo defines an experimental portion of the scope of the Management 67 Information Base (MIB) for use with Internet community network management 68 protocols. The particular focus of this MIB scope extension is the 69 presentation and management of objects for network topology information. 71 Constructs and encodings for these topology objects has been specified in a 72 manner consistent with the dictates of the SNMP Version 2 SMI. 74 3. Introduction 76 3.1 The SNMP Management Framework 78 The network managment framework of the Internet community is the Simple 79 Network Management Protocol Version 2. Information for transfer through the 80 SNMP [2] concern managed objects. These managed objects are accessed through 81 a virtual information store, referred to as a Management Information Base 82 (MIB). Managed objects in this MIB are encoded using a subset of ASN.1, 83 identified in the SNMPv2 Structure of Managed Information [1], or SMI. Each 84 such object type and its attributes are defined using an OBJECT-IDENTIFIER 85 macro, as defined in the SMI. Each such managed object type is placed within 86 the administrative scope of a subset of the ASN.1-encoded hierarchy defined 87 within the SMI. An object type's OBJECT-IDENTIFIER macro definition 88 references that placement. The OBJECT-IDENTIER macro for an object type also 89 supplies a name associated with the object type. For purposes of symbolic and 90 linguistic reference, this name is used to reference the object type 91 notationally. 93 An SNMP MIB agent is a process which provides access to instances of MIB 94 object types by linking the object type data with its instance value. SNMP 95 protocol operations are used to associate different access types varying in 96 access level and granularity with the instance data provided in the protocol 97 data units (PDU's) embodying those protocol operations. 99 3.2 The Neo-MIB 101 The Network Element Object MIB (NeoMIB) is a portion of the SNMP MIB which 102 defines an organization of objects acting as members of a connected network 103 topology, and provides a means for an agent implementing the NeoMIB to 104 represent data about such topological member elements. 106 The MIB serves only as a means to express the relationships and internal and 107 external attributes of those data, and not to define or constrain means of 108 collecting this relationship and attribute data. 109 It is also important to note that the NeoMIB, unlike other MIBs commonly 110 deployed throughout the Internet community, concerns itself with management of 111 topology and not with the management of manageable elements of that topology. 112 There is no direct operational linkage between the NeoMIB and management 113 capabilities (or constraints thereupon) of the agents, or their managed 114 elements, unlike the operational access provided by, for example, the 115 Interfaces MIB [4], or the writable object types of MIB-II [5]. This provides 116 an important limitation in the exposure to operational security considerations 117 a NeoMIB agent would otherwise pose. 119 4. Background and Concepts 121 The NeoMIB refers to a number of concepts and constructs which should be 122 defined at the outset, to differentiate the usage of names associated with 123 them from their, in some cases subtly, different usage in other MIBs and 124 Internet documents. 126 4.1 Agent Model Types 128 A variety of MIBs and elemental organization schemes underlying them have been 129 proposed out of the current work of the IETF ptopo Working Group. One of the 130 key differentiators has been the presumptions of the role of the agent in the 131 way the MIB is deployed. We will use the term Topology MIB to generically 132 describe a type of MIB to manage topology data (of which, of course, the 133 NeoMIB is one). 135 A Topology MIB which assumes a System Agent model for its agent implementation 136 plays the role of a conventional MIB agent without proxy scope or capability. 137 It represents only those elements which are nodally local to the agent 138 process. To present an interconnected topology, a management application 139 would have to query across some interconnected scope for presence of 140 individual agents, and do a set of SNMP retrieval operations on each to 141 collect the local topology data for each agent node. The management 142 application must then, presumably with some connection context information 143 present in the MIB data available from each agent, assemble a collected view 144 of the topology on each. A clear benefit here in the interests of simplified 145 agent implementation is the lack of any requirement for an explicit external 146 (relative to the agent chassis) discovery protocol (although one could 147 conceive of the usability for one in such an agent model, and in fact the 148 primary proposal for a MIB which presumes this Agent Model does have features 149 which leverage such an ability). 151 The other agent model has been called a Server Agent. This does act in the 152 role of a "proxy" for topological members represented by such a single agent 153 within a given scope. A number of nodes, connections, and so forth have data 154 available on them from a single agent which is construed as authoritative for 155 that scope. For purposes of redundancy and possible convergence across agents 156 of any underlying discovery protocol, there may be redundancy; management of 157 that redundancy is an incumbent requirement on any underlying discovery 158 protocol intended to be employed by such an agent or its discovery process. 159 Of course, static configuration of topology data is also a viable underlying 160 means of populating topology data to be exposed through the MIB agent; as 161 mentioned previously, it is not a dictate of the MIB specification that any 162 particular means of discovery or such data population be employed or precluded 163 as long as it provides directly or in combination with other means enough data 164 for an agent to represent minimum conformance groups of the MIB. 165 Nevertheless, a Server Agent implies richer minimum capabilities for whatever 166 that method constitutes. On the other hand, this places a complete 167 presentation control for a topology subset at the single point of control of 168 that agent. Also, this provides a data model which extends effortlessly to 169 deployment in an agent-manager mixed implementation (since distributed 170 topology subsets can be collected for agent exposure at a "superagent" higher 171 in the conceptual management structure). 173 The primary reason why a System Agent model vs. a Server Agent model doesn't 174 just represent a smooth continuum of scope is the fact that a Server Agent MIB 175 must present some construct for containment of its topological scope (at a 176 minimum; using this or other containment constructs for further topological 177 segmentation within the data presented is also an option). 179 This is not to say that a hybrid implementation is not possible. The NeoMIB 180 is such a server-based and system-based agent. Capability for a server-based 181 implmentation has been provided to leverage the distribution possibilities 182 described above. However, there is a relative complexity of Server-based 183 Topology MIB agent which does not lend such agents to being deployed on nodes 184 which lack sufficient processing power and related resources (process space 185 RAM, secondary virtual store, etc.) for such complexity. With such nonuniform 186 deployment, by defintion, the capability for connected System Agents to 187 represent a collected complete topology accurately is diminished. Hence, 188 capability exists to have a NeoMIB agent "declare" itself as system-based, and 189 foregoing exposing containment of the chassis-level representation it contains 190 in its NeoMIB instance data. 192 4.2 Segments 194 The unit of containment as present in the NeoMIB operating as a Server Agent 195 is a Segment. A segment contains both connectable entities (in the 196 topological sense), and potentially other segments if there is any nesting 197 implied. 199 An essential specific property of segments (where they are used) is the 200 segment boundary type. This provides an advisory to the management 201 application which can interpret boundary types as to the nature of the segment 202 bounding interfaces in terms of passiveness and reachability of traffic, in 203 addition to providing an advisory attribute which can be mapped to segment 204 display characteristics in the typical topological map. Bounding points for 205 the purposes of this discussion are transit points from one segment to another 206 (assuming such adjacent segments are present--there is no technical reason why 207 an adjacent segment must be present to nevertheless dictate a boundary of a 208 given segment). Hence, boundary types include such options as routed, and 209 passthrough (the latter, for example, presumably appropriate for a segment 210 which is bounded by a layer 2 hub). They correspond with the predominant 211 behavior of the ports which act as gateways from a segment to another segment 212 (if present), as it relates conceptually to the flow of network traffic from 213 that segment to the other segment. 215 Like many other such constructs in the NeoMIB, the specific usage and exact 216 meaning of bounding types for instances for segment objects are at the 217 discretion of the agent--it is not the role of the MIB to provide a didactic 218 guideline as to what constitutes the difference between "switched" and 219 "bridged" in the case of traversal from segment to segment over a port which 220 displays characteristics of both--but agent implementors are guided to adhere 221 to canonical definitions of the meaning of such terms as they apply to their 222 well-known placement in network literature and products. 224 4.3 Connection Points 226 The NeoMIB expands on the traditional notion of the "port" or "interface" as 227 being, among other essential things, the receptacles of all connections 228 between elements in a topology. For reasons of consistency in modeling and 229 navigation through a topology, such an interface is grouped with another 230 construct, the connection nexus (see section 6.4) to assemble an arbitrary 231 construct called a Connection Point. Connection Points are the start or 232 terminus (depending on orientation, of course) of any traversable connection 233 in the NeoMIB. Connection Points are codified as their own layer in the MIB 234 to aggregate the common characteristics and serve as a "container type" for 235 those topological elements (interfaces, connection nexes) which they comprise. 237 5. Requirements 239 The following requirements are construed as essential in the development of 240 the NeoMIB. 242 5.1 Relationship to other MIBs 244 To avoid redundancy of information, and to as well avoid competition of means 245 of modeling characteristics and attributes of underlying physical topological 246 elements, the ptopo group has agreed to strive to defer to the support for 247 representation on those characteristics and attributes in agents supporting 248 prior Draft Standard MIBs wherever possible. 250 This has particular applicability to the elemental detail provided by the core 251 MIB-II [5] and Entity MIB [3] agents supported on any represented agent node 252 in the topology. The detail and relationships depicted by these agents' data 253 should not be supplanted or duplicated by any object type specified in the 254 NeoMIB. For a Server Agent NeoMIB agent implementation, this involves 255 maintaining the presence of an external reference corresponding to a given 256 element (interface, adapter) to indices within applicable tables in agents 257 running on topology nodes which contain those elements. This, however, leads 258 to a characteristic synchronization problem currently (see section 9), which 259 is why some level of visibility of those elements must be provided by the 260 NeoMIB agent topology representation itself. In short, there is no way to 261 assure accuracy of, for example, a entityPhysicalIndex corresponding to a row 262 which represents an adapter card on the target agent instance of the Entity 263 MIB, as reflected in the reference of that index provided by the NeoMIB Server 264 Agent's neoMibAdapterTable neoAdapterExtIndex instance, since the actual agent 265 on the target node could have experienced power cycle or other cause for 266 reindexing of these Entity MIB rows since the last time of target agent poll 267 by the neoMIB agent. 269 5.2 Support of Navigability 271 A major purpose of a Server Agent approach is to present cross-topological 272 physical navigability from a single point of orientation (the Server Agent and 273 its view of a segment). In general, support for a management station's 274 ability to assembled a connection matrix as a function of analyzing a topology 275 is an incumbent requirement for any Topology MIB (this term is being used here 276 generically) which is going to represent a topology usefully. The NeoMIB is 277 designed to present negligible impediments to assembling an enterprise-wide 278 topology, which might otherwise be encountered as a weakness of the 279 containment model, or weakness in the connection model itself. 280 To the latter point, a word should be said about one of the motivations for 281 the connection nexus notion. Where a connection is modeled as strictly point- 282 to-point between physical interface or other single-receptacle Connection 283 Points (to use our own term), several limitations arise in representing 284 complex topologies. One is the fact that some physical or logical network 285 attachment points are in fact multidrop, and means of modeling this using 286 simplex connection constructs lead to anatomical deficiencies in the 287 represented network. If no other construct is available to remedy this 288 condition, a deviation, and in some cases a marked deviation, from the 289 underlying physical topology must be presented by the Topology MIB agent. 291 5.3 Extensibility between System and Service Agents 293 Finally, despite the fact that a NeoMIB agent is at its most useful and 294 efficient (from the point of view of a management application) mode of 295 deployment as a Server Agent, reasons discussed previously stand as to why 296 this is a less-than-useful minimum ante for agent conformance. 298 A group of System Agents implemented within a subnetwork must be able to 299 provide a reconcilable, navigable (see 5.2) represented image of a topology, 300 which, while lacking some of the details of containment and requiring some 301 extra work on the part of the management application to collectively assemble 302 same, should not preclude or limit this provision. 304 6. MIB Structure 306 6.1 Agent-level Data 308 At the global scope of the agent, a number of attributes regarding agent 309 operation and implementation are provided. Consistent with the discussion of 310 a management application's being able to work with either a System or Server 311 Agent, an indicator is given as to the model of an agent instance. A 312 timestamp is provided to allow a management application to easily detect if a 313 modification has been made which would suggest a need to repoll other parts of 314 the agent data to look for new, deleted, or modified data. 316 Finally, an advisory table which lists discovery mechanisms by autonomous type 317 is given. This is strictly advisory, and agents which do not support 318 discovery mechanisms which are tagged to a locus in a standard, experimental 319 or proprietary administrative scope need not present any row data in the 320 neoAgentDiscoveryMechanismTable. 322 6.2 ElementObject table 324 The neoMibElementObjectTable has a row for every element in the topology. 325 Entries in all element type-specific tables discussed below 326 (neoMibSegmentTable, neoMibHostTable) have a corresponding row entry in this 327 table as well. The neoMibSegmentEntry has fields which aggregate all common 328 properties of these type-specific table entries. Examples of such attributes 329 are type itself, display string, creation time (within the MIB instance data), 330 etc. Perhaps the most important is the neoMibElementIndex, which acts as a 331 primary reference index throughout references elsewhere in the MIB. 333 6.3 Segment table 335 Segment-level table entries, which per the preceding discussion acts to 336 "augment" the underlying segment object's identity as depicted in a 337 neoMibElementObjectTable row, need to present fields to orient the segment as 338 a container element, and potentially as a contained element as well (since 339 segments can be arbitrarily "nested" within other segments). 341 Additionally, rows in the neoMibSegmentTable have a field, 342 neoSegmentLastModified, which acts as a container-level "last time modified" 343 timestamp. This timestamp is to be updated when any of the elements in the 344 segment (or more correctly, any of the interfaces in the segments or the host, 345 connection, or adapter elements which reference those interfaces--see 6.4.1) 346 have any of their instance data modified. This allows a management 347 application to do poll for topology modifications as follows. 348 neoAgentLastModified can be polled at the top level of the MIB, awaiting a 349 change from a reference value (management application's last modified 350 reference time). Upon detecting a change in neoAgentLastModified, the 351 management application can do SNMP protocol operations to enumerate all 352 segments' neoSegmentLastModified values, collecting all such values in excess 353 of the management application's retained previous neoAgentLastModified value 354 for the agent. The collection of segments with their neoSegmentLastModified 355 in excess of this retained reference value represent the set of segments 356 suitable for segment-ordered reenumeration of contained prior known elements 357 to update what is at that point presumably an out-of-date (or nonexistent) 358 segment element set on the management application. 360 It should be noted that in the case of a System Agent implementation, or 361 Server Agent representations of logically "flat" topologies, there may be no 362 segmentation either available or called for. In these cases, all interfaces 363 will have no containing segment references (neoInterfaceParentSegment = 0 for 364 their neoMibInterfaceTable rows), and there will be no entries in the 365 neoMibSegmentTable. 367 6.4 Connection Points 369 Connection Points simply represent, currently, one point in the MIB hierarchy. 370 Connection nexuses and Interfaces are the subcontained groups for this level. 371 Connection Points combine all connectable entities. As it turns out, there 372 are currently no attributes for reindexing and aggregation in some 373 neoMibConnectionPointTable, so one is not defined. 375 Since Connection Points embody all of the fundamental navigable units within 376 the NeoMIB, the motivation for maintaining this point in the hierarchy is 377 navigational within the MIB. An efficient algorithm for initial scan by a 378 NeoMIB-aware management application of a NeoMIB topology using SNMP GET 379 protocol operations would proceed by enumerating entirely through the 380 neoMibCnxnPoint scope, picking up all of its contained object type instances 381 and their attributes in associated table row entries. In this way, the most 382 elemental "building blocks" from the point of view of connection creation and 383 connection reference integrity are present as those connections (and other 384 referencing elements such as hosts, adapters, and segments) reference these 385 connection points. 387 6.4.1 Interfaces 389 Hence, interfaces are a conceptual "subtype" of the connection point. The 390 NeoMibInterfaceEntry is the richest aggregate object type in the MIB. The 391 fields here need to be sufficient for placement within the topology, for 392 behavior within the segment, and to additionally provide enough context 393 information to allow direct access to the management agent on which this 394 interface physically resides in the network. 396 To satisfy this requirement, the NeoMibInterfaceEntry has references to the 397 "parenting" segment, host, and adapter by each such "parenting" element's 398 neoMibElementIndex value. Agent implementors are encouraged to ensure 399 association to a neoMibHostTable via a value in the NeoMibInterfaceEntry 400 neoInterfaceParentHost field to allow a management application to have a 401 predictable display mechanism for interfaces (i.e., attached to a host 402 topology object). However, lack of association to a neoMibAdapterTable entry 403 is perfectly acceptable when lack of adapter-level detail is available through 404 the discovery mechanism or when an interface is construed to be "motherboard- 405 based" or in some other way not placed on an expansion adapter. 407 The neoInterfacePrimaryAddrDomain and neoInterfacePrimaryAddress provide agent 408 addressing data for this interface's controlling management agent. 410 The neoInterfaceIsSegmentBoundary defines whether this interface corresponds 411 to a boundary in the parent segment. Since the neoMibSegmentTable entry 412 indexed by an interface's neoInterfaceParentSegment type has a field in its 413 own right, neoSegmentBoundaryType, defining the presumed traversability of 414 this interface in its function as a segment boundary interface, these two 415 characteristics (the interface's segment boundary role and its role as a type 416 of interface of neoSegmentBoundaryType) conceptually are linked. 417 The relative complexity of this determination is what causes us to formally 418 decouple this role as a segment boundary from its role in general, as 419 reflected in the neoInterfacePortBehavior of a neoMibInterfaceTable entry. 420 All interfaces (regardless of the value of neoInterfaceIsSegmentBoundary) can 421 represent a "port behavior" through this field. Port behaviors are 422 cumulative, using the same mechanism that sysServices in [4] employs to 423 combine multiple values. The values available here are designed to provide a 424 flexible indicator as to the layer at which traffic can be processed into and 425 across the interface. This allows a management application to make 426 determinations on display characteristics for an interface's host in a display 427 based on supported services, in addition to determinations on base 428 reachability of one interface to another under varying conditions of payload 429 type and size, presumed delay, etc. 431 6.4.2 Connection Nexuses 433 A connection nexus is in some respects a basic Connection Point as it has been 434 defined in 6.4. Since it does not represent a physical entity, it can be used 435 to aggregate connections to a logical entity, such as a WAN Service Provider, 436 which may conceptually reside in the middle of a topology. It may also be 437 used to represent a physical aggregation of connection (such as a multidrop 438 bus connection point in LAN wiring). 440 Its lightweight minimal attribute exposure in its neoMibCnxnNexusTable row 441 instance provides one primary enabling feature--an easy way to associate 442 multiple connection objects to a given connection nexus by reference. A 443 connection nexus is intended to be used in any situation in the modeling of 444 the topology where multiple connections originating from one logical or 445 physical place are required. While there is no way to specifically prevent it 446 currently, it is NOT intended that multiple neoMibConnectionTable entries 447 reference the same neoMibInterfaceTable entry, and agent implementors SHOULD 448 NOT allow this condition to occur, so as to allow the management application 449 to have a predictable connected topological element set to handle for display 450 and layout purposes. 452 A Connection Nexus does reference a segment through its neoMibCnxnNexusTable 453 row instance neoCnxnNexusParentSegment value, but is notably NOT capable of 454 specifying itself as a boundary to that segment. This is since it would not 455 be possible in this architecture to determine where internally to the 456 connection nexus the segment is split on. Secondarily, initial implementation 457 experience has shown that the usefulness of specifying a connection nexus 458 point as a segment boundary is negligible. 460 6.4.3 Connections 462 Consistent with the preceding description of Connection Point-derived 463 elements, a connection is simply a table entry with two references, each to 464 some such Connection Point-scoped topology element. 466 As stated earlier, while there is no way to specifically prevent it currently, 467 it is NOT intended that multiple neoMibConnectionTable entries reference the 468 same neoMibInterfaceTable entry, and agent implementors SHOULD NOT allow this 469 condition to occur. An unlimited number of neoMibConnectionTable entries CAN 470 reference the same neoMibCnxnNexusTable row entry, however. 472 Finally, agent implementors SHOULD NOT allow a condition to have the 473 neoConnectionEP1 field and neoConnectionEP2 field of the same 474 neoMibConnectionTable entry reference the same neoMibCnxnNexusTable or 475 neoMibInterfaceTable entry under any condition. 477 6.5 Host table 479 Node-level entities are represented by rows in the neoMibHostTable. The only 480 field supported in a row instance of this table provides a neoHostSysObjectId 481 which differs from the MIB-II sysObjectID in that it does not need to be 482 directly coupled to the management subsystem. 484 6.6 Adapter table 486 Adapter-level detail, where available through a discovery mechanism employed 487 by a neoMIB agent's discovery process, is represented through rows in the 488 neoMibAdapterTable. A row in this table contains the same kind of object 489 administrative reference in its neoAdapterSysObjectId that is has been 490 described for the neoHostSysObjectId. 492 Additionally, a reference is contained to the encountered entPhysicalIndex of 493 the entPhysicalIndex in the Entity MIB entPhysicalTable which is either in the 494 local Entity MIB agent data (in the case of a Server or System Agent's 495 neoMibAdapterTable corresponding to an adapter on the same chassis that the 496 neoMIB agent is running on), or which was encountered by a Server Agent NeoMIB 497 from the agent on the node on which this adapter physically resides in the 498 network. This reference is the neoMibAdapterExtEntityIndex field of the 499 neoMibAdapterTable. 501 Where this index is nonzero and hence to be construed as valid, several 502 conditions should be able to be assumed by a management application. One is 503 that the neoMibAdapterExtEntityIndex was valid (was a valid entPhysicalIndex 504 in the applicable Entity MIB agent data) at the TimeStamp marked at the 505 neoMibElementCheckpointTime field for the neoMibElementObjectTable row entry 506 with the same neoMibElementIndex value as this neoMibAdapterTable entry has. 507 Another is that as a byproduct of that validity of association, the 508 entPhysicalClass value in the entPhysicalTable row with this 509 neoMibAdapterExtEntityIndex in this Entity MIB agent data had a PhysicalClass 510 value of `container (5)' at that neoMibElementCheckpointTime time of last 511 encounter. 513 Where available, this Entity MIB reference is necessary to properly qualify 514 the placement of adapter cards relative to each other, for example, which are 515 primarily connected to a system bus and which are in turn daughter-cards to 516 each other. As far as the neoMibAdapterTable is concerned, these are simply 517 entries at a peer level with no indicator present from the neoMIB agent data 518 to represent this kind of placement information. 520 7. Network Element Object MIB (neoMIB) 522 NEO-MIB DEFINITIONS ::= BEGIN 524 IMPORTS 525 MODULE-IDENTITY, OBJECT-TYPE, experimental 526 FROM SNMPv2SMI 527 TEXTUAL-CONVENTION, TDomain, TAddress, DisplayString, RowPointer, 528 TimeStamp, DateAndTime, TruthValue 529 FROM SNMPv2-TC 530 MODULE-COMPLIANCE, OBJECT-GROUP 531 FROM SNMPv2-CONF; 533 neoMib MODULE-IDENTITY 534 LAST-UPDATED "9612260000Z" 535 ORGANIZATION "IETF Physical Topology Working Group" 536 CONTACT-INFO 537 " 538 WG E-mail: ptopo@3Com.com 539 Subscribe: ptopo-request@3com.com 541 Ken Jones 542 ptopo Working Group Chair 543 Bay Networks, Inc. 544 4401 Great America Parkway 545 PO Box 58185, MS SC01-04 546 Santa Clara, CA 95052-8185 547 kjones@baynetworks.com 549 Wayne F. Tackabury 550 NeoMIB Document Author 551 Netsuite Development, L.P. 552 321 Commonwealth Rd., Ste. 300 553 Wayland, MA 01778 554 Tel: (508) 647-3114 555 waynet@netsuite.com" 557 DESCRIPTION 558 "The MIB module for representing a topology of one or more 559 chassis-level network elements, with connections from logical 560 connection point network elements to other connection point 561 network elements on other chassis. The agent supporting an 562 instance of this MIB can be representing only the chassis 563 on which the agent resides and optionally its attached 564 connections and other subelements, or can be representing a 565 group of such chassis-level systems and sublements, optionally 566 with each of their connections represented as well. The 567 former is known as a topology system agent, the latter is 568 known as a topology service agent." 569 ::= {experimental 666} -- replace with IANA ptopo assignment 571 neoMibObjects OBJECT IDENTIFIER ::= { neoMib 1 } 572 -- Groups within neoMIB 574 neoMibAgent OBJECT IDENTIFIER ::= { neoMibObjects 1 } 575 neoMibElementObject OBJECT IDENTIFIER ::= { neoMibObjects 2 } 576 neoMibSegment OBJECT IDENTIFIER ::= { neoMibObjects 3 } 577 neoMibHost OBJECT IDENTIFIER ::= { neoMibObjects 4 } 578 neoMibCnxnPoint OBJECT IDENTIFIER ::= { neoMibObjects 5 } 579 neoMibInterface OBJECT IDENTIFIER ::= { neoMibCnxnPoint 1 } 580 neoMibCnxnNexus OBJECT IDENTIFIER ::= { neoMibCnxnPoint 2 } 581 neoMibConnection OBJECT IDENTIFIER ::= { neoMibObjects 6 } 582 neoMibAdapter OBJECT IDENTIFIER ::= {neoMibObjects 7} 584 -- Textual conventions used throughout neoMIB 586 NeoIndex ::= TEXTUAL-CONVENTION 587 DISPLAY-HINT "d" 588 STATUS current 589 DESCRIPTION 590 "Integer index used to reference network element objects 591 back to their primary containing table." 592 SYNTAX INTEGER (0..2147483647) 594 NeoNodalType ::= TEXTUAL-CONVENTION 595 DISPLAY-HINT "d" 596 STATUS current 597 DESCRIPTION 598 "Type of neoMib element instance. This allows a mapping from 599 container types (neoElementObject, neoCnxnPoint) to actual 600 types of element objects as represented by an entry in 601 neoMibSegmentTable, neoMibInterfaceTable etc. (in this 602 example, neoSegment, neoInterface respectively)." 603 SYNTAX INTEGER { 604 other(1), -- in what table would "other" show up? 605 neoSegment(2), 606 neoHost (3), 607 neoInterface(4), 608 neoCnxnNexus(5), 609 neoAdapter(6) 610 } 612 -- neoMibAgent section. 613 -- this contains nodal entries for data describing this agent's 614 -- configured role and current agent status. 616 neoAgentType OBJECT-TYPE 617 SYNTAX INTEGER { 618 other(1), 619 unknown(2), 620 topoSystemAgent(3), 621 topoServiceAgent(4) 622 } 623 MAX-ACCESS read-only 624 STATUS current 625 DESCRIPTION 626 "The type of this agent. Among defined types, a 627 topoSystemAgent only represents the logical chassis on 628 which the agent resides, along with any known connected 629 partners. A topoServiceAgent corresponds with a topology 630 server implementation, where a community of nodes is being 631 represented (along with any known connections amongst 632 their connectionPoints) by this agent." 633 ::= { neoMibAgent 1 } 635 neoAgentLastModified OBJECT-TYPE 636 SYNTAX TimeStamp 637 MAX-ACCESS read-only 638 STATUS current 639 DESCRIPTION 640 "The time of last modification of any of the topological 641 data available from this server. More specifically, the 642 last time that any adds, removes, changes in value or 643 linkage of any of the row entries in the 644 neoMibElementObjectTable occurred relative to sysUpTime. 645 A management application can monitor this object to 646 determine appropriate points to re-query the rows of 647 the neoMibElementObjectTable and its higher level tables 648 for updates." 649 ::= { neoMibAgent 2 } 651 neoAgentOperState OBJECT-TYPE 652 SYNTAX INTEGER { 653 other (1), 654 unknown (2), 655 startup (3), 656 collecting (4), -- in dyanmic/other data collection 657 idle (5), -- idle/processing agent requests 658 shutdown(6), 659 error-state (7) 660 } 661 MAX-ACCESS read-only 662 STATUS current 663 DESCRIPTION 664 "The current overall operational state of this neoMIB 665 agent process. This is intended to be a rough 666 approximation of current state as suitable for a 667 management application's choice of graphical indicators 668 of this agent and to guide other choice of agent selection 669 and diagnostics." 670 ::= { neoMibAgent 3} 672 neoAgentDiscoveryMechanismTable OBJECT-TYPE 673 SYNTAX SEQUENCE OF NeoAgentDiscoveryMechanismEntry 674 MAX-ACCESS not-accessible 675 STATUS current 676 DESCRIPTION 677 "This table contains one row for each marked mechanism 678 or algorithm of discovery as used for discovery of at 679 least one connectionPoint as represented by a row in 680 the neoMibElementObjectTable." 681 ::= { neoMibAgent 4 } 683 neoAgentDiscoveryMechanismEntry OBJECT-TYPE 684 SYNTAX NeoAgentDiscoveryMechanismEntry 685 MAX-ACCESS not-accessible 686 STATUS current 687 DESCRIPTION 688 "Information about a mechanism or algorithm of discovery 689 as used for discovery of at least one connectionPoint 690 as represented by a row in the neoMibElementObjectTable." 691 INDEX { neoAgentDiscoveryMechanismIndex } 692 ::= { neoAgentDiscoveryMechanismTable 1 } 694 NeoAgentDiscoveryMechanismEntry ::= SEQUENCE { 695 neoAgentDiscoveryMechanismIndex NeoIndex, 696 neoAgentDiscoveryMechanismIdentifier AutonomousType 697 } 699 neoAgentDiscoveryMechanismIndex OBJECT-TYPE 700 SYNTAX NeoIndex 701 MAX-ACCESS not-accessible 702 STATUS current 703 DESCRIPTION 704 "Index for this discovery mechanism entry." 705 ::= { neoAgentDiscoveryMechanismEntry 1 } 707 neoAgentDiscoveryMechanismIdentifier OBJECT-TYPE 708 SYNTAX AutonomousType 709 MAX-ACCESS read-only 710 STATUS current 711 DESCRIPTION 712 "Identifier of a vendor-specific or other registered 713 discovery type, heuristic, or algorithm. The value 714 { 0 0 } (a NULL object identifier) indicates static or 715 other unidentified discovery means. Otherwise, each row 716 denotes a discovery mechanism outside of the administrative 717 scope of this MIB (for example, within a vendor scope). " 718 ::= { neoAgentDiscoveryMechanismEntry 2 } 720 -- neoMIBElementObject section. Rows of the table contained herein 721 -- describe all MIB object instances which will be present in other 722 -- tables specific to the instance type (neoMIBSegmentTable, 723 -- neoMIBInterfaceTable, etc.), and will decribe properties and 724 -- attributes of all such objects. 726 neoMibElementObjectTable OBJECT-TYPE 727 SYNTAX SEQUENCE OF NeoMibElementEntry 728 MAX-ACCESS not-accessible 729 STATUS current 730 DESCRIPTION 731 "This table contains one row of every object, regardless of 732 object nodal type, about which this agent is aware and 733 capable of delivering data." 734 ::= { neoMibElementObject 1 } 736 neoMibElementEntry OBJECT-TYPE 737 SYNTAX NeoMibElementEntry 738 MAX-ACCESS not-accessible 739 STATUS current 740 DESCRIPTION 741 "Information about a single neoMib object." 742 INDEX { neoMibElementIndex } 743 ::= { neoMibElementObjectTable } 745 NeoMibElementEntry ::= 746 SEQUENCE { 747 neoMibElementIndex NeoIndex, 748 neoMibElementType NeoNodalType, 749 neoMibElementDescription DisplayString, 750 neoMibElementCreationTime DateAndTime, 751 neoMibElementCheckpointTime TimeStamp, 752 neoMibElementRowStatus RowStatus 753 } 755 neoMibElementIndex OBJECT-TYPE 756 SYNTAX NeoIndex 757 MAX-ACCESS not-accessible 758 STATUS current 759 DESCRIPTION 760 "Index of this element within this base element object 761 table. This index permeates through to references in 762 other tables pertinent to the nodal type of this object." 763 ::= { neoMibElementEntry 1 } 765 neoMibElementType OBJECT-TYPE 766 SYNTAX NeoNodalType 767 MAX-ACCESS read-only 768 STATUS current 769 DESCRIPTION 770 "Nodal type of this element. All elements ultimately resolve 771 to a nodal type denoting their role in the topology 772 represented by this MIB instance. Such role is reflected 773 for the element of this row by the value of its 774 neoMibElementType." 775 ::= { neoMibElementEntry 2 } 777 neoMibElementDescription OBJECT-TYPE 778 SYNTAX DisplayString 779 MAX-ACCESS read-only 780 STATUS current 781 DESCRIPTION 782 "A text string describing this element. No presumptions are 783 made about the contents or requirement of this informational 784 string, and it may very well be a null DisplayString." 785 ::= { neoMibElementEntry 3 } 787 neoMibElementCreationTime OBJECT-TYPE 788 SYNTAX DateAndTime 789 MAX-ACCESS read-only 790 STATUS current 791 DESCRIPTION 792 "Historic creation date of this object in this topology. If 793 this object was entered statically or is otherwise a part 794 of a topology which was created in a prior operational cycle 795 of this agent, then this time may precede the time of sysUp 796 for this agent." 797 ::= { neoMibElementEntry 4 } 799 neoMibElementCheckpointTime OBJECT-TYPE 800 SYNTAX TimeStamp 801 MAX-ACCESS read-only 802 STATUS current 803 DESCRIPTION 804 "Time, relative to sysUpTime, that this element was last 805 last affirmatively encountered by the agent. A TimeStamp 806 value of zero indicates that this element has not been 807 encountered and verified by the agent process within this 808 operational cycle of this agent. Note that such a zero 809 value is not to be construed as an indication of actual 810 element (e.g., network node) dysfunction or disappearance, 811 since elements which were added to the neo Topology 812 statically may never be checkpointed after their static 813 addition to the topology base. Alternately, in a highly 814 dynamic discovery agent methodology, guidelines for aging 815 out of elements which have not been encountered in some 816 max threshold are beyond the scope of this MIB." 817 ::= { neoMibElementEntry 5 } 819 neoMibElementRowStatus OBJECT-TYPE 820 SYNTAX RowStatus 821 MAX-ACCESS read-only 822 STATUS current 823 DESCRIPTION 824 "Status of this row in the neoMibElementObjectTable." 825 ::= { neoMibElementEntry 6 } 827 -- neoMibSegment section. This contains top-level groupings of the 828 -- network elements exposed by this agent as a function of their 829 -- content and bounding operation within the network. Note in 830 -- particular that a segment can contain another segment. 832 neoMibSegmentTable OBJECT-TYPE 833 SYNTAX SEQUENCE OF NeoMibSegmentEntry 834 MAX-ACCESS not-accessible 835 STATUS current 836 DESCRIPTION 837 "This table contains one row for every segment. Note that 838 each segment will also have a row in the 839 neoMibElementObjectTable. An agent which wishes to express 840 a topology image which contains only the agent chassis, its 841 ports and known connections could forego supporting any 842 retrieval capability for segment data, pursuant to its 843 ConformanceGroup options." 844 ::= { neoMibSegment 1 } 846 neoMibSegmentEntry OBJECT-TYPE 847 SYNTAX NeoMibSegmentEntry 848 MAX-ACCESS not-accessible 849 STATUS current 850 DESCRIPTION 851 "Information about a single segment." 852 INDEX { neoMibElementIndex } 853 ::= { neoMibSegmentTable 1 } 855 NeoMibSegmentEntry ::= 856 SEQUENCE { 857 neoSegmentLastModified TimeStamp, 858 neoSegmentBoundaryType INTEGER, 859 neoSegmentParentSegment NeoIndex, 860 neoSegmentRowStatus RowStatus 861 } 863 neoSegmentLastModified OBJECT-TYPE 864 SYNTAX TimeStamp 865 MAX-ACCESS read-only 866 STATUS current 867 DESCRIPTION 868 "A timestamp, relative to sysUpTime, of last modification 869 of this segment, any of its contained interfaces, hosts, 870 or connection points. A management application can use 871 this to efficiently determine sections of a topology 872 exposed by this topology server which require update 873 retrieval for synchronization with current topology 874 state." 875 ::= { neoMibSegmentEntry 1 } 877 neoSegmentBoundaryType OBJECT-TYPE 878 SYNTAX INTEGER { 879 other (1), 880 unknown (2), 881 unbounded (3), 882 routed (4), 883 switched (5), 884 bridged (6), 885 passthrough (7) 886 } 887 MAX-ACCESS read-only 888 STATUS current 889 DESCRIPTION 890 "An indication as to the nature of the boundary interfaces 891 of this segment. This will allow a management or simulation 892 application to make rough determinations as to reachability, 893 layer 2 and 3 collision domains, and other properties 894 governing intersegment traffic flow. The value 895 'unbounded (3)' could be used for either a self-contained 896 segment or segment physically not connected to any other, or 897 for a dual-homed segment boundary node type where no traffic 898 automatically flows from one segment to another without 899 application-level intervention. The value 'bridged (6)' 900 would pertain to an 802.1(d) or other formalized model 901 (e.g., Token Ring MAU) of layer 2 bridge segment boundary 902 interface. The value 'passthrough (7)' is used to denote, 903 for example, a segment bounded by passive layer 2 ports 904 such as a segment of devices connected through a 802.3 hub." 905 ::= { neoMibSegmentEntry 2 } 907 neoSegmentParentSegment OBJECT-TYPE 908 SYNTAX NeoIndex 909 MAX-ACCESS read-only 910 STATUS current 911 DESCRIPTION 912 "The neoMibElementIndex of the segment which is logically 913 considered to be the 'parent' of the segment denoted by this 914 row instance. The semantics of 'parent' are under the control 915 of the agent, but agent implementors are encouraged to use 916 the implications of the values of neoSegmentBoundaryType in 917 setting up parent relationships for segments. In all other 918 respects, this allows the management application to display 919 a logical and consistent view of containment of segment 920 groupings of network elements. A neoSegmentParentSegment 921 value of zero indicates that this segment is unparented, or 922 is at the 'top level' of the segment containment scope." 923 ::= { neoMibSegmentEntry 3 } 925 neoSegmentRowStatus OBJECT-TYPE 926 SYNTAX RowStatus 927 MAX-ACCESS read-only 928 STATUS current 929 DESCRIPTION 930 "Status of this row in the neoMibSegmentTable." 931 ::= { neoMibSegmentEntry 4 } 933 -- NeoMibHost section. This section embodies the neoMib-pertinent 934 -- data on chassis-level network elements. 936 neoMibHostTable OBJECT-TYPE 937 SYNTAX SEQUENCE OF NeoMibHostEntry 938 MAX-ACCESS not-accessible 939 STATUS current 940 DESCRIPTION 941 "This table contains one row for every host. While 942 hosts can be individually retrieved through this table 943 in coordination with their presence as base elements in the 944 neoMibElementObjectTable, as a primary means of navigating 945 through segment inclusion or element-to-element connection, 946 a management application will probably want to first examine 947 the interfaces by segment or unsegmented indexing, and map 948 to host-level interface containment from there." 949 ::= { neoMibHost 1 } 951 neoMibHostEntry OBJECT-TYPE 952 SYNTAX NeoMibHostEntry 953 MAX-ACCESS not-accessible 954 STATUS current 955 DESCRIPTION 956 "Information about a single host." 957 INDEX { neoMibElementIndex } 958 ::= { neoMibHostTable 1 } 960 NeoMibHostEntry ::= 961 SEQUENCE { 962 neoHostSysObjectId AutonomousType, 963 neoHostRowStatus RowStatus 964 } 966 neoHostSysObjectId OBJECT-TYPE 967 SYNTAX AutonomousType 968 MAX-ACCESS read-only 969 STATUS current 970 DESCRIPTION 971 "A vendor or other identification of chassis by management 972 agent subsystem or other attribute of administrative scope 973 implied by AutonomousType. Since this need not be tied 974 specifically to management subsystem, this may or may not 975 be the same as sysObjectID from RFC 1907. An object 976 identifier of null, or {0 0} denotes no such identification 977 attribute is present for this host." 978 ::= { neoMibHostEntry 1 } 980 neoHostRowStatus OBJECT-TYPE 981 SYNTAX RowStatus 982 MAX-ACCESS read-only 983 STATUS current 984 DESCRIPTION 985 "Status of this row in the neoMibHostTable." 986 ::= { neoMibHostEntry 2 } 988 -- neoMibInterface section. This describes all attributes of interfaces, 989 -- as connectable, addressable, and otherwise host-contained navigable 990 -- endpoints of the collected network topology. The collection of 991 -- interfaces under the hierarchical grouping neoMibCnxnPoint reflects 992 -- the fact that they share a crucial common property with the other 993 -- member of that hierarchical grouping (neoMibCnxnNexus) that they 994 -- can be endpoints of a connection, that is, can be referenced by 995 -- neoMibConnectionTable row entries. 997 neoMibInterfaceTable OBJECT-TYPE 998 SYNTAX SEQUENCE OF NeoMibInterfaceEntry 999 MAX-ACCESS not-accessible 1000 STATUS current 1001 DESCRIPTION 1002 "This table contains one row for every interface. Note that 1003 each interface will also have a row in the 1004 neoMibElementObjectTable. " 1005 ::= { neoMibInterface 1 } 1007 neoMibInterfaceEntry OBJECT-TYPE 1008 SYNTAX NeoMibInterfaceEntry 1009 MAX-ACCESS not-accessible 1010 STATUS current 1011 DESCRIPTION 1012 "Information about a single interface. This is primarily 1013 indexed by parent segment to accomodate easy per-segment 1014 table traversal by management application requests." 1015 INDEX { neoInterfaceParentSegment, neoMibElementIndex } 1016 ::= { neoMibInterfaceTable 1 } 1018 NeoMibInterfaceEntry ::= 1019 SEQUENCE { 1020 neoInterfaceParentSegment NeoIndex, 1021 neoInterfaceParentHost NeoIndex, 1022 neoInterfaceParentAdapter NeoIndex, 1023 neoInterfacePrimaryAddrDomain TDomain, 1024 neoInterfacePrimaryAddress TAddress, 1025 neoInterfaceExtIndex NeoIndex, 1026 neoInterfaceIsSegmentBoundary TruthValue, 1027 neoInterfacePortBehavior INTEGER, 1028 neoInterfaceRowStatus RowStatus 1029 } 1031 neoInterfaceParentSegment OBJECT-TYPE 1032 SYNTAX NeoIndex 1033 MAX-ACCESS read-only 1034 STATUS current 1035 DESCRIPTION 1036 "A reference to the neoMibElementIndex of the segment 1037 containing this interface. A NeoIndex value of zero 1038 denotes a lack of containment to a segment, and is 1039 obviously the only allowable value in an unsegmented 1040 topology." 1041 ::= { neoMibInterfaceEntry 1 } 1043 neoInterfaceParentHost OBJECT-TYPE 1044 SYNTAX NeoIndex 1045 MAX-ACCESS read-only 1046 STATUS current 1047 DESCRIPTION 1048 "A reference to the neoMibElementIndex of the host element 1049 containing this interface. A NeoIndex value of zero denotes 1050 a lack of containment to a host. Such a lack of containment 1051 is not recommended by agent implementations in any interface 1052 instance exported by this table with a neoInterfaceRowStatus 1053 value of 'ready' since such interfaces do not map readily 1054 to a rational means of display for querying management 1055 applications. 1057 For interfaces whose row instances have a 1058 neoInterfaceParentHost nonzero value but a zero value for 1059 neoInterfaceParentAdapter, the interface can be construed to 1060 be 'embedded' or logically motherboard-attached on the parent 1061 host." 1062 ::= { neoMibInterfaceEntry 2 } 1064 neoInterfaceParentAdapter OBJECT-TYPE 1065 SYNTAX NeoIndex 1066 MAX-ACCESS read-only 1067 STATUS current 1068 DESCRIPTION 1069 "A reference to the neoMibElementIndex of the adapter element 1070 containing this interface. A NeoIndex value of zero denotes 1071 a lack of containment to an adapter. Such a lack of 1072 containment where an interface row instance has a nonzero 1073 neoInterfaceParentHost value can be construed to denote 1074 an interface 'embedded' or logically motherboard-attached 1075 on the chassis referenced by neoInterfaceParentHost." 1076 ::= { neoMibInterfaceEntry 3 } 1078 neoInterfacePrimaryAddrDomain OBJECT-TYPE 1079 SYNTAX TDomain 1080 MAX-ACCESS read-only 1081 STATUS current 1082 DESCRIPTION 1083 "Type of transport service for the primary transport address 1084 associated with the management subsystem of this interface. 1085 A TDomain value of {0 0} is allowable to denote 1086 lack of known or expressed management subsystem addressability 1087 from this row instance, provided that 1088 neoInterfacePrimaryAddress is also zero. Where nonzero, NOTE 1089 that this is not necessarily the same as the Tdomain for an 1090 address this interface is assuming in its network operation 1091 in the topology" 1092 ::= { neoMibInterfaceEntry 4 } 1094 neoInterfacePrimaryAddress OBJECT-TYPE 1095 SYNTAX TAddress 1096 MAX-ACCESS read-only 1097 STATUS current 1098 DESCRIPTION 1099 "Primary transport address associated with the management 1100 agent subsystem of this interface, as governed by 1101 neoInterfacePrimaryAddrDomain. A null value of 1102 neoInterfacePrimaryAddress is allowable to denote 1103 lack of known or expressed mangement subsystem addressability 1104 from this row instance, provided that 1105 neoInterfacePrimaryAddrDomain is also zero. NOTE that this 1106 is not necessarily the same as the address this interface is 1107 assuming in its network operation in the topology." 1108 ::= { neoMibInterfaceEntry 5 } 1110 neoInterfaceExtIndex OBJECT-TYPE 1111 SYNTAX NeoIndex 1112 MAX-ACCESS read-only 1113 STATUS current 1114 DESCRIPTION 1115 "Value of the ifIndex associated with the row of the 1116 ifTable in the MIB-II agent data for the agent last found 1117 at neoInterfacePrimaryAddress, where said ifTable row 1118 corresponds with this interface." 1119 ::= { neoMibInterfaceEntry 6 } 1121 neoInterfaceIsSegmentBoundary OBJECT-TYPE 1122 SYNTAX TruthValue 1123 MAX-ACCESS read-only 1124 STATUS current 1125 DESCRIPTION 1126 "Indicates whether this port represents a boundary with 1127 respect to its containing segment, if any. If the 1128 neoInterfaceParentSegment instance for this row is 1129 zero, then neoInterfaceIsSegmentBoundary should be 1130 set to a TruthValue value of 'false'. Otherwise, this 1131 value denotes whether this port is a boundary port in 1132 its segment, which is to say whether it represents 1133 a point of traversal into any colocated segments 1134 relative to the containing segment of this interface." 1135 ::= { neoMibInterfaceEntry 7 } 1137 neoInterfacePortBehavior OBJECT-TYPE 1138 SYNTAX INTEGER (0..4294967295) 1139 MAX-ACCESS read-only 1140 STATUS current 1141 DESCRIPTION 1142 "A set of network behaviors being exhibited in this topology 1143 by this interface. The value is a sum. This sum initially 1144 takes the value zero. Then, for each behavior, B, in the 1145 range 1 through 32, that this node performs servicesfor, 2 1146 raised to (B - 1) is added to the sum. 1148 1 = unknown 1149 2 = other 1150 3 = endnode (having 'layer 3' addressability) 1151 4 = power backup (e.g., UPS) 1152 5 = management agent (e.g., has SNMP agent) 1153 6 = topology MIB management agent 1154 (presumes 'management agent') 1155 7 = hub (passive) 1156 8 = switch (LAN/WAN) 1157 9 = route 1158 10 = serial translation (e.g., modem, DSU) 1159 11 = stream concentration (or active hub, e.g., FDDI) 1160 12 = address translation (e.g., RFC1577 LIS) 1161 13 = bridge (i.e., 802.1) 1162 14 = electromechanical transceiver 1163 Combination of these values are mutually exclusive and have no 1164 explicit limitation or provision on how they can be bound." 1165 ::= { neoMibInterfaceEntry 8 } 1167 neoInterfaceRowStatus OBJECT-TYPE 1168 SYNTAX RowStatus 1169 MAX-ACCESS read-only 1170 STATUS current 1171 DESCRIPTION 1172 "Status of this row in the neoMibInterfaceTable." 1173 ::= { neoMibInterfaceEntry 9 } 1175 -- neoMibCnxnNexus section. This describes relevant attributes 1176 -- of connection nexes, as simple topological containers for groups 1177 -- of logical endpoints of connections, which endpoints are not 1178 -- integrated into chassis elements, et al, such as interfaces are. 1179 -- Conceptually, interfaces are seen as being able to reference a 1180 -- single neoMibConnectionEntry per interface, where a connection 1181 -- nexus can be referenced by multiple neoMibConnectionEntries, 1182 -- since the notion of an "endpoint" of a connection nexus is never 1183 -- really formally exposed. Note that such an "endpoint" of a 1184 -- connection nexus can be connected to an interface, or to another 1185 -- connection nexus. 1187 neoMibCnxnNexusTable OBJECT-TYPE 1188 SYNTAX SEQUENCE OF NeoMibCnxnNexusEntry 1189 MAX-ACCESS not-accessible 1190 STATUS current 1191 DESCRIPTION 1192 "This table contains one row for every connection nexus. 1193 Note that each connection nexus will also have a row in the 1194 neoMibElementObjectTable. " 1195 ::= { neoMibCnxnNexus 1 } 1197 neoMibCnxnNexusEntry OBJECT-TYPE 1198 SYNTAX NeoMibCnxnNexusEntry 1199 MAX-ACCESS not-accessible 1200 STATUS current 1201 DESCRIPTION 1202 "Information about a single connection nexus." 1203 INDEX { neoMibElementIndex } 1204 ::= { neoMibCnxnNexusTable 1 } 1206 NeoMibCnxnNexusEntry ::= 1207 SEQUENCE { 1208 neoCnxnNexusParentSegment NeoIndex, 1209 neoCnxnNexusNumConnections INTEGER, 1210 neoCnxnNexusRowStatus RowStatus 1211 } 1213 neoCnxnNexusParentSegment OBJECT-TYPE 1214 SYNTAX NeoIndex 1215 MAX-ACCESS read-only 1216 STATUS current 1217 DESCRIPTION 1218 "A reference to the neoMibElementIndex of the segment 1219 containing this connection nexus. A NeoIndex value 1220 of zero denotes a lack of containment to a segment, and is 1221 obviously the only allowable value in an unsegmented 1222 topology." 1223 ::= { neoMibCnxnNexusEntry 1 } 1225 neoCnxnNexusNumConnections OBJECT-TYPE 1226 SYNTAX INTEGER (1..4096) 1227 MAX-ACCESS read-only 1228 STATUS current 1229 DESCRIPTION 1230 "Number of current references to this connection nexus 1231 to be found amongst the rows of the neoMibConnectionTable. 1232 This is to facilitate ease of evaluating all connections 1233 to this connection domain from other neoMibCnxnPoints" 1234 ::= { neoMibCnxnNexusEntry 2 } 1236 neoCnxnNexusRowStatus OBJECT-TYPE 1237 SYNTAX RowStatus 1238 MAX-ACCESS read-only 1239 STATUS current 1240 DESCRIPTION 1241 "Status of this row in the neoMibCnxnNexusTable." 1242 ::= { neoMibCnxnNexusEntry 3 } 1244 -- neoMibConnection section. This section details all connections 1245 -- between network elements elsewhere derived from neoMibCnxnPoint. 1247 neoMibConnectionTable OBJECT-TYPE 1248 SYNTAX SEQUENCE OF NeoMibConnectionEntry 1249 MAX-ACCESS not-accessible 1250 STATUS current 1251 DESCRIPTION 1252 "This table contains one row for every connection. Note that 1253 each connection will also have a row in the 1254 neoMibElementObjectTable. " 1255 ::= { neoMibConnection 1 } 1257 neoMibConnectionEntry OBJECT-TYPE 1258 SYNTAX NeoMibConnectionEntry 1259 MAX-ACCESS not-accessible 1260 STATUS current 1261 DESCRIPTION 1262 "Information about a single connection." 1263 INDEX { neoMibElementIndex } 1264 ::= { neoMibConnectionTable 1 } 1266 NeoMibConnectionEntry ::= 1267 SEQUENCE { 1268 neoConnectionEP1 NeoIndex, 1269 neoConnectionEP2 NeoIndex, 1270 neoConnectionRowStatus RowStatus 1271 } 1273 neoConnectionEP1 OBJECT-TYPE 1274 SYNTAX NeoIndex 1275 MAX-ACCESS read-only 1276 STATUS current 1277 DESCRIPTION 1278 "neoMibElementIndex of the neoMib element derived from 1279 neoMibCnxnPoint which comprises one end of this duplex 1280 connection. This should be an index to a valid row in 1281 the neoMibElementObjectTable, and should not be the same 1282 as the instance of neoConnectionEP2 in this row." 1283 ::= { neoMibConnectionEntry 1 } 1285 neoConnectionEP2 OBJECT-TYPE 1286 SYNTAX NeoIndex 1287 MAX-ACCESS read-only 1288 STATUS current 1289 DESCRIPTION 1290 "neoMibElementIndex of the neoMib element derived from 1291 neoMibCnxnPoint which comprises one end of this duplex 1292 connection. This should be an index to a valid row in 1293 the neoMibElementObjectTable, and should not be the same 1294 as the instance of neoConnectionEP1 in this row." 1295 ::= { neoMibConnectionEntry 2 } 1297 neoCnxnNexusRowStatus OBJECT-TYPE 1298 SYNTAX RowStatus 1299 MAX-ACCESS read-only 1300 STATUS current 1301 DESCRIPTION 1302 "Status of this row in the neoMibConnectionTable." 1303 ::= { neoMibConnectionEntry 3 } 1305 -- Adapter section. 1307 neoMibAdapterTable OBJECT-TYPE 1308 SYNTAX SEQUENCE OF NeoMibAdapterEntry 1309 MAX-ACCESS not-accessible 1310 STATUS current 1311 DESCRIPTION 1312 "This table contains one row for every adapter." 1313 ::= { neoMibAdapter 1 } 1315 neoMibAdapterEntry OBJECT-TYPE 1316 SYNTAX NeoMibAdapterEntry 1317 MAX-ACCESS not-accessible 1318 STATUS current 1319 DESCRIPTION 1320 "Information about a single adapter." 1321 INDEX { neoMibElementIndex } 1322 ::= { neoMibAdapterTable 1 } 1324 NeoMibAdapterEntry ::= 1325 SEQUENCE { 1326 neoAdapterSysObjectId AutonomousType, 1327 neoAdapterExtIndex NeoIndex, 1328 neoAdapterRowStatus RowStatus 1329 } 1331 neoAdapterSysObjectId OBJECT-TYPE 1332 SYNTAX AutonomousType 1333 MAX-ACCESS read-only 1334 STATUS current 1335 DESCRIPTION 1336 "A vendor or other identification of adapter by management 1337 agent subsystem or other attribute of administrative scope 1338 implied by AutonomousType. An object identifier of null, 1339 or {0 0} denotes no such identification attribute is present 1340 for this adapter." 1341 ::= { neoMibAdapterEntry 1 } 1343 neoAdapterExtIndex OBJECT-TYPE 1344 SYNTAX NeoIndex 1345 MAX-ACCESS read-only 1346 STATUS current 1347 DESCRIPTION 1348 "Value of the entPhysicalIndex associated with the 1349 row of the entPhysicalTable in the Entity MIB agent 1350 data for the agent last found at the 1351 neoInterfacePrimaryAddress for any of the 1352 NeoMibInterfaceTable entries which reference this 1353 neoMibAdapterEntry neoMibElementIndex, where said 1354 entPhysicalTable row corresponds with this adapter." 1355 ::= { neoMibAdapterEntry 2 } 1357 neoAdapterRowStatus OBJECT-TYPE 1358 SYNTAX RowStatus 1359 MAX-ACCESS read-only 1360 STATUS current 1361 DESCRIPTION 1362 "Status of this row in the neoMibHostTable." 1363 ::= { neoMibAdapterEntry 3 } 1365 END 1366 8. Security Considerations 1368 The neoMIB is intended to provide read access to data which has been collected 1369 through some discovery mechanism outside of the scope of the MIB. In its 1370 current form, creation or write access is not provided for any of its object 1371 types. Security implications of the availability on data of any of its 1372 represented topological elements is seen as the province of security 1373 considerations for individual discovery and population mechanisms, if at all. 1374 As a result, the deployment of the neoMIB is not seen as being relevant to any 1375 further security requirements or implications. 1377 9. Open Issues (as of 15 January 1997) 1379 * I'm unclear as to whether there is a move afoot to preserve the integrity 1380 of the chassis MIB PhysicalIndex values as there has been for the ifIndex 1381 of recent. I'm under the impression that the consensus in the ifMIB 1382 group and others is to require implementors to not "reuse" ifIndices 1383 of interfaces which have gone away for some reason. Is the same true 1384 of Entity MIB indices? That would partially alleviate the "cross 1385 agent" synchronization problem of the NeoMIB latching another agent's 1386 index values in neoAdapterExtIndex and neoInterfaceExtIndex. More 1387 fundamentally, is this acceptable to people? I really don't know how 1388 we can have a Server Agent implementation AND preserve the primacy 1389 of the Entity MIB otherwise. 1391 * Considerations for interoperability of Server Agents and System Agents 1392 within the same Segment physical space need to be addressed. 1394 * There are general considerations for system agents as well which need 1395 exploring and potential elaboration in the document. How are "adjacent" 1396 nodes sorted out between adjacent neoMIB agents representing each 1397 other as connected neighbors? I'd say by some combination of mgmt. 1398 addr + ifIndex (aka neoInterfaceExtIndex), but do we need to provide 1399 guidelines for management application writers here? 1401 * Acceptability of a single segment bounding type? This is for 1402 simplicity sake, basically. 1404 * In general, should altorithms for MIB scope traversal (interfaces 1405 -> hosts -> segments, et al) be provided? There are a number of ways 1406 to do it, but none are "trivial" really. The discussion in sec. 4.2 1407 on a segment-ordered MIB polling algorithm does not discuss removal of 1408 any "deleted" segments. 1410 10. Acknowledgements 1412 Gratitude is owed to Maria Greene (Ascom-Nexion) for helping to refine a 1413 number of ideas here and for keeping me from throwing some truly silly 1414 constructs in here. Prior contributions from Greene, Prakash Desai (Bay 1415 Networks) and H. Nikolaus Schaller (Lehrstuhl fure Datenverarbeitung) have 1416 been influential in the developmnent of the NeoMIB. Finally, my Netsuite 1417 colleagues Kevin Cronin, Dan Tonelli, and Lazarus Vekiarides have been 1418 instrumental in developing the conceptual underpinnings of what has become 1419 the NeoMIB. 1421 11. Bibliography 1423 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1424 Waldbusser, "Structure of Management Information for Version 2 of the 1425 Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. 1427 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1428 Waldbusser, "Protocol Operations for Version 2 of the Simple Network 1429 Management Protocol (SNMPv2)", RFC 1905, January, 1996 1431 [3] McCloghrie, K, and Bierman, A., "Entity MIB using SMIv2", RFC 2037, 1432 October, 1996. 1434 [4] McCloghrie, K. and Kastenholtz, F., "Interfaces Group Evolution", RFC 1435 1573, January 1994. 1437 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1438 Waldbusser, "Management Information Base for Version 2 of the Simple 1439 Network Management Protocol (SNMPv2)", RFC 1907, January, 1996. 1441 12. Author's Address 1443 Wayne F. Tackabury 1444 Netsuite Development, L.P. 1445 321 Commonwealth Rd., Ste. 300 1446 Wayland, Massachusetts 01778 1448 Phone: (508) 647-3114 1449 Fax: (508) 647-3112 1450 Email: waynet@netsuite.com