[peterw@pdd.3com.com: Chassis MIB Proposal]
Bob Stewart <rlstewart@eng.xyplex.com> Fri, 11 December 1992 15:34 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA14467; Fri, 11 Dec 92 10:34:28 -0500
Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA14438; Fri, 11 Dec 92 10:33:31 -0500
Received: by xap.xyplex.com id <AA25895@xap.xyplex.com>; Fri, 11 Dec 92 11:06:47 -0500
Date: Fri, 11 Dec 1992 11:06:47 -0500
Message-Id: <9212111606.AA25895@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: chassismib@cs.utk.edu
Subject: [peterw@pdd.3com.com: Chassis MIB Proposal]
From: peterw@pdd.3com.com Date: Fri, 11 Dec 92 15:26:48 GMT To: rlstewart@eng.xyplex.com Subject: Chassis MIB Proposal Bob, Thanks for your 'ack' to my mail. A favour in your role as chassis MIB chair! A short time ago I sent a 3 part chassis MIB proposal to the group. I've tried a number times from various systems. Most I think didn't arrive, the ones that did were corrupted. I've now got a Unix account but I get an error message every time I try to send to chassismib@cs.utk.edu. Our MIS people are looking into this. I've included the proposal below in a 1 part. If you could forward this to the group I'd much appreciate it. thanks in anticipation Pete Definitions of Managed Objects for a Chassis Containing Multiple Logical Network Devices November 24, 1992 Proposal By: Peter Wilson Peter_Wilson@3Com.com Introduction ============ At the IETF meeting in Washington the definition of a chassis was discussed. It seemed that between those present there was some ambiguity about what we wanted the model to look like. Following on from that discussion it was proposed that the chassis MIB become somewhat more generic. My aims in this proposal are as follows: 1) To produce a more generic MIB. By this I want to get away from the idea that a chassis contains slots, entities and segments. slots and segments are somewhat implementation specific concepts. Segments may not even exist in some network chassis implementations. 2) Reduce the complexity of relationships between parts of the MIB. The current MIB defines a table of relationships between an entity, a slot and a segment. From that model its unclear what relationships could exist and how the configuration can be changed. From the application point of view configuration of the device could be very difficult without having explicit knowledge of each chassis. 3) Produce a MIB that provides good information for a generic chassis management application, even if a particular chassis does not contain knowledge of all the various things contained in that chassis. 4) Make visible the components that make up a physical entity. In the current proposal this information is implicit in the relationship table. One does not know from the MIB what logical components are available on a card. To change a relationship involves destroying that relationship and creating another. There is no continuity between the various operations and one has no way of identifying the component of a module being used in an entity. 5) Move towards SNMPv2 (still a good way to go!) This proposal needs specific MIB definitions to be added (moved from existing proposal) to describe power supplies sensors etc. The Model ========= A chassis is a generic 'container'. It can be any shape and size and can have any position. Examples of things that constitute chassis are the traditional network hub, PABX as well as less common items such as a room, building, campus etc. One chassis can recursively contain other chassis, eg a building could contain some rooms which in turn contain cabinets that contain network hubs. There are two views of a chassis. Firstly the physical view. The physical view considers the chassis to comprise a number of different types of compartment. Each type of compartment is specialised to hold a particular type of item or module. Examples of compartment types would be corridors, rooms, elevator shafts, network card slots and power supply bays. At any instant in time each of these compartments may be occupied or empty. Secondly there is the logical or functional view. In this view the chassis is considered to contain a number of 'entities'. Each entity provides some function. Examples of entities would be company projects and Network Repeaters. An entity is implemented using parts from one or more physical modules. It is necessary to describe the relationship between physical module and logical entity. For the purposes of this relationship a physical module is considered to comprise a number of logical components (resources?). A number of logical components are joined together to construct an entity. To illustrate these concepts consider a company to be the chassis. In this example the physical modules are floors of a building and the logical entities projects. Each floor comprises a number of people which are the components from which project teams are constructed. Each person is specialised for a particular role within a project. Floor Function:Person Project Implemented By (module) (component) (entity) (relationship) -------- ------- -------------- 1 - Marketing:Pete xyz-thing Marketing:Pete Marketing:Jeff Development:Mike Development:Mike Manufacturing:Dave Manufacturing:Alan abc-thing Marketing:Jeff 2 - Marketing:Jane Development:Sharon Development:Sharon Development:Michele Manufacturing:Dave Manufacturing:Alan 3- Development:Michele Marketing:Paul Development:James Analysis of this example provide some interesting relationships that apply equally to a network type device: 1) Each physical entity comprises a number of logical components that can be used in the construction of an entity. 2) A logical component of one type may be substituted for a different component of the same type in a logical entity. eg James may be substituted for Mike but not for Jeff. 3) It is possible that at some time not all components are part of entities. It is however necessary to know all components that exist and the current use or otherwise of those components. Having looked at a generic example consider a practical example of a chassis that contains modules for the token ring and Ethernet. In this example assume that each Ethernet and each Token Ring card contain 4 ports. There currently exist 4 entities in the chassis, two Ethernet repeaters and 2 Token Rings. The chassis contains 4 locations that can contain modules and the configuration is as follows: Slot Number Contains 1 Ethernet Repeater Card 2 802.5 Port Card 3 Ethernet Repeater Card 4 802.5 Port Card The logical configuration of the chassis at a particular time is as follows: Entity Implemented By ------ -------------- Repeater 1 Module 1, Port 1, 2, 3 Module 3, Port 2 Repeater 2 Module 1, Port 4 Module 3, Port 1, 3 Token Ring 1 Module 2, Port 1, 2 Token Ring 2 Module 2, Port 3 Module 4, Port 3 ---------------------------------------- Module 2, Port 4 - Not currently used Module 3, Port 4 - " " " Module 4, Port 1, 2, 4 - " " " Note that a MIB to represent and configure devices such as this must make all components of all cards visible and allow the configuration of those components into entities. Now suppose that an operator needs an additional Ethernet repeater. In order to do this a new Repeater entity is created and some of the repeater ports are assigned to that entity. eg: create Repeater 3 assign Module 3, Port 4 to Repeater 3 -- Currently unassigned assign Module 3, Port 1 to Repeater 3 -- Moved from Repeater 2 >> NOTE >> ==== >> This model does not use the concept of Segment as currently specified >> in the chassis MIB draft. There are a number of reasons for this: >> >> 1) Segment is an implementation specific concept closely allied with >> the idea of a dedicated backplane. A number of chassis implementations >> do not physically have this concept/restriction. >> >> 2) There is no analogous concept to segment in other types of chassis, >> for example a building or company. >> >> 3) The 3 way mapping of module, entity and segment is complex and >> difficult to implement in such a way that all information is >> visible. In this model the three way module/entity/segment relationship >> is replaced with a simpler two way component/entity relationship. >> >> There are a number of ways to achieve the same ends using this model. >> Such implementations are described below: Combining Components into Entities (Network Chassis) ================================== 1. Implicit Assignment ---------------------- This strategy requires the most effort from the chassis agent but provides the best and easiest model for both the application writer and the best abstraction for the user. It is applicable to both chassis that use a hardwired backplane and those that use central or distributed switching services to implement functions. The chassis is required to implement a number of entities. The number and type of entity implemented by a particular chassis depends on the physical capabilities and design of that chassis. For example one chassis may be designed with 3 Ethernet type busses on a backplane. In this chassis it is possible to create 3 repeaters that use components from more than one physical module. The chassis may also be capable of implementing a number of additional repeaters provided only components on the same card are used. Implicit assignment says that the chassis is required to marshal its inherent resources to best meet the requested configuration of the manager. The managers requests are communicated by the creation and destruction of entities and by the assignment of components to entities. In the example of a chassis with 2 Ethernet backplanes the stragtegy of the agent could be as follows: manager agent ----------------------------------------------------------------- create Repeater record repeaters existence assign Mod 1, Port 1 add component to repeater, don't need a to repeater backplane yet! assign Mod 1, Port 2 add component to repeater, don't need a to repeater backplane yet! assign Mod 2, Port 1 Repeater crosses card boundaries so find a spare backplane and assign that to this repeater. Note that if there are no spare backplanes then the assignment is rejected. Note that this approach makes repeater implementation transparent to a user. The model is identical regardless of whether the chassis uses backplanes, has central/distributed switching or any other implementation strategy. 2. Explicit Assignment ---------------------- This is a more manual approach. The effort required in the agent is potentially somewhat less but the savings are really nominal. In this model the manager is responsible for assigning backplanes. A backplane is simply a physical module in the same way that a repeater card is a module. Because it is a module it also has logical components that can be assigned to entities. Now consider the same example of a repeater chassis with 2 backplanes. The example is the same as above: Create a repeater and assign a number of repeater ports to that repeater: manager agent ----------------------------------------------------------------- create Repeater record repeaters existence assign Mod 1, Port 1 add component to repeater, don't need a to repeater backplane yet! assign Mod 1, Port 2 add component to repeater, don't need a to repeater backplane yet! assign Mod 2, Port 1 Request rejected. There is no assigned connection path to allow ports on different cards to be assigned to the same repeater. assign Ether B'plane Repeater can now span cards. 1 to repeater assign Mod 2, Port 1 Request successful. NOTE: Variations on this theme are possible but the idea remains the same. For example one could statically create 2 repeaters that always exist to represent the two backplanes. Ports could be assigned to those repeaters. Additional repeaters could be created but would not be allowed to span cards. In a particular chassis there will also be a number of fixed entities that always exist, although the components assigned to that entity may differ. ---------------------------------------------------------------------- chasEntity OBJECT IDENTIFIER ::= { chassis 2 } chasConfig OBJECT IDENTIFIER ::= { chassis 4 } chasKnownTypes OBJECT IDENTIFIER ::= { chassis 7 } chasPhysical OBJECT IDENTIFIER ::= { chassis 8 } chasComponent OBJECT IDENTIFIER ::= { chassis 9 } chasKnownLocations OBJECT IDENTIFIER ::= { chassis 10 } phyLocationTable OBJECT-TYPE SYNTAX SEQUENCE OF PhyLocationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " A chassis comprises a number of modular locations. There are a number of different types of location. For example there are locations that can contain power supplies, others that contain fans and yet others that can contain modular network cards. Further types can be defines. For example the chassis MIB may be used to describe a building where the locations are rooms, corridors, elevators etc. This table summarises the different classes of location and the number of occurrances of each type in the chassis. This table is indexed on an integer that locally identifies the location type. Informational columns identify each of the types uniquely by an object identifier." ::= { chasPhysical 1 } phyLocationEntry OBJECT-TYPE SYNTAX PhyLocationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " An entry in this table describes a type of location. For example a network slot, power-supply bay etc" INDEX { locationTypeIndex } ::= { phyLocationTable 1 } PhyLocationEntry ::= SEQUENCE { locationTypeIndex INTEGER, locationType OBJECT IDENTIFIER, locationCount INTEGER, locationName DisplayString } locationTypeIndex OBJECT-TYPE SYNTAX INTEGER ( 1..65535 ) ACCESS not-accessible STATUS mandatory DESCRIPTION " This is a simple index into this table and one of the indices into the physical configuration table. One can traverse this table and determine all the types of 'slot' that exist within this chassis." ::= { phyLocationEntry 1 } locationType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION " This column uniquely identifies the 'type' of the slot. A number of defined values exists, namely networkDeviceSlot powerSupplyBay fanPosition backplanePosition other types can be added on a vendor specific basis." ::= { phyLocationEntry 2 } locationCount OBJECT-TYPE SYNTAX INTEGER ( 1..65535 ) ACCESS read-only STATUS mandatory DESCRIPTION " This object identifies the number of instances of this location that exist within this chassis. For example if there were a chassis that had 10 slots availble for network devices then the value of this column would be 10." ::= { phyLocationEntry 3 } locationName OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION " Each type of location in the chassis is given a textual name. This is very useful for an application that knows how to deal with generically defined locations suh as those defined within this MIB, but that are only capable of dealing with other types as 'unknown'. In this case the name string can be used to at least sensibly describe the location to the user." ::= { phyLocationEntry 4 } -- phyConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PhyConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " This table identifies the current configuration of the chassis. The physical configuration is defined in terms of physical items that reside at certain physical locations in the chassis. A physical location is described by a location type and a location. For example a location type may be a power supply bay and the location is 1 indicating power supply bay number 1. Note that this table is indexed on locationTypeIndex and phyLocation. locationIndex is borrowed (shared with) from the phyLocationTable Note that the table only contains information about locations that are currently occupied by some entity." ::= { chasPhysical 2 } phyConfigEntry OBJECT-TYPE SYNTAX PhyConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " An entry in this table describes the contents of a populated 'slot' within the chassis. For example a particular row may contain an entry for a power support in a particular power supply bay or could describe a network card in a particular card slot." INDEX {locationTypeIndex, phyLocation} ::= { phyConfigTable 1 } PhyConfigEntry ::= SEQUENCE { phyLocation INTEGER, phyContentsObject OBJECT IDENTIFIER, phySwVersion DisplayString, phyHwVersion DisplayString, phySerialNumber DisplayString, phyDescription DisplayString, phyLastChangeTime TimeTicks, phyAdminStatus INTEGER, phyOperStatus INTEGER } phyLocation OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS mandatory DESCRIPTION " The location defines which instance of a particular class of locations is being descibed by this entry. For example if the index for a row is has locationTypeIndex refering to networkDeviceSlot and phyLocation is 7 then this entry in the table is describing the contents of the network card in slot 7." ::= { PhyConfigEntry 1 } phyContentsObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION " Each physical item contained in the chassis is a stand-alone unit. This type of that unit is defined through allocation of a product object id. This column is the object id for the product at the location described by this entry." ::= { PhyConfigEntry 2 } phySwVersion OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION " If the physical item described by this entry in the table contains software then this column provides a string representation of the version of that software. Not all items contain software. In these cases this column will contain the NULL string" ::= { PhyConfigEntry 3 } phyHwVersion OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION " The version number of the hardware described by this entry in the table." ::= { PhyConfigEntry 4 } phySerialNumber OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION " The serial number of the module represented by this entry in the table." ::= { PhyConfigEntry 5 } phyDescription OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION " Textual description of this module. Using this string a manager can describe an entity even if it is unaware of the function of the card. This can go some way to preventing an update in an application simply because a new type of card has been introduced, for example a new repeater card with a different physical interface." ::= { PhyConfigEntry 6 } phyLastChangeTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of MIB-II's sysUpTime (in the agent supporting this chassis MIB) at which a module was last inserted into this slot. If no module has been inserted into this slot since the system last restarted this object will have the value 0 (zero)." ::= { PhyConfigEntry 7 } phyAdminStatus OBJECT-TYPE SYNTAX INTEGER { enable(2), disable(3), reset(4), test(5) } ACCESS read-write STATUS mandatory DESCRIPTION " Provides the adminstratively desired state of the given module. A module is enabled by writing the value enable(2). A module may be deactivated by writing a value of disable(2). In a disabled state a module does exist within the chassis but is benign. A disabled module is available for subsequent activation. Writing a value of reset(4) specifies that the module should initiate a reset sequence. This value allows a suspect module to be 'kicked' into a reset state without having to physically walk to the chassis and perform the reset operation. Writing a value of test(5) specifies that a module should intiate a test sequence. NOTE: Not all of these values need be supported for all modules in the chassis. There are occassions when allowing certain operations would compromise the state of the chassis, for example disabling the one and only power-supply may not be an appropriate action." ::= { PhyConfigEntry 8 } phyOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), testing(3), operational(4), resetInProgress(5), warning(6), nonFatalError(7), fatalError(8) } ACCESS read-only STATUS mandatory DESCRIPTION " Provides operational status of the module. The following are possible definitions of the values. The exact definition of the values is implementation specific. A value of other(1) implies some undetermined state, possibly as a result of setting phyAdminStatus to a value of disable(3). A value of invalid(2) could have the possible meaning that the module exists but the chassis manager has no direct control over the module. A value of testing(3) may be a diagnostic state. A value of operational(4) implies that the entity is running with no errors or warnings. State resetInProgress(5) implies equivalent of setting phyAdminStatus to reset(4). The states of warning(6), nonFatalError(7), fatalError(8) reflect conditions detected during operation. The entity may or may not be still functional. For example if a modules value of phyAdminStatus is disable(3) and is set to enable(2) then phyOperStatus may enter a state of testing(3) then change to a value of operational(4)." ::= { PhyConfigEntry 9 } -- The chasEntity group. Implementation of the chasEntity group -- is mandatory. -- Entity Table chasEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about the 'logical' networking devices (entity) in this chassis." ::= { chasEntity 1 } chasEntityEntry OBJECT-TYPE SYNTAX ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information concerning an entity in the chassis. SNMP requests allow rows to be added and removed from this table. Adding a row to the table signals the creation of a new logical network device. Removing a row signals the deletion of a logical network device. Note that some implementations may required some or all rows in this table to be read-only through SNMP." INDEX { chasEntityIndex } ::= { chasEntityTable 1 } ChasEntityEntry ::= SEQUENCE { chasEntityIndex INTEGER, chasEntityType OBJECT IDENTIFIER, chasEntityDescr DisplayString, chasEntityAdminStatus INTEGER, chasEntityOperStatus INTEGER, chasEntityTimeStamp TimeTicks, chasEntityTargetParty Party, chasEntityCommunity OCTET STRING, chasEntityTDomain OBJECT IDENTIFIER, chasEntityTAddress TAddress, chasEntityRowStatus RowStatus } chasEntityIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION " A unique index for the entity for which this entry contains information." ::= { chasEntityEntry 1 } -- chasEntityFunction OBJECT-TYPE -- REMOVED -- Note that the bitmap entity function value is not generic and cannot -- be extended to support new sevices as they become available. The -- recommended way to determine the function of an entity is to either -- decode the chasEntityObjectID OR access the entity -- directly to determine the function of the entity. chasEntityType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION " This value identifies the type of the functional entity. This value is generally read only but may be written when requesting the agent to create a new entity. Note that not all entities may be created. Some chassis may not allow any entities to be created!. Standard types are: repeater8023 Ethernet Repeater tokenRing8025 Token Ring fddiRing FDDI Ring bridge Bridge Entity router Router Entity brouter Bridge/Router Combined Entity terminalServer Terminal Server chassis A contained (nested) chassis powerSupply Power Supply networkMonitor Network Monitoring Device chassisFan Fan Entity displayPanel Display Panel" ::= { chasEntityEntry 3 } chasEntityDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION A textual description of the entity. When a new entity is created it will be given a default description that may subsequently be over written." ::= { chasEntityEntry 4 } -- chasEntityVersion OBJECT-TYPE -- REMOVED -- Because a logical entity can be distributed over parts of a number of -- physical modules it is not appropriate to have version information -- about an entity. The version information belongs with the constituent -- physical parts of the chassis. -- -- eg a repeater may be constructed from two repeater cards. Card 1 -- is version 1.0 H/W of hardware and version 1.2 S/W. Card 2 is -- version 1.1 H/W and 2.0 S/W. There is no meaningful way of -- identifying the version of the entity. It is possible in some systems to -- identify the version of the agent S/W being used to provide a view -- of an entity, but this information does not belong in the entity -- table. chasEntityAdminStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), -- none of the following enable(2), disable(3), reset(4), test(5) } ACCESS read-write STATUS mandatory DESCRIPTION " Provides the administratively desired state of the given entity. An entity is activated by writing a value of enable(2). An entity may be de-activated by writing a value of disable(3). In a disabled state, a entity does exist within the given chassis, but is benign. A disabled entity is available for subsequent activation. Writing a value of reset(4) specifies an entity should initiate a reset sequence. Writing a value of test(5) specifies an entity should initiate a testing sequence. Agent support of the writing of any of the values of this object is implementation-specific. For example, this object might be read only for entities that disabling would compromise the integrity of the chassis." ::= { chasEntityEntry 6 } chasEntityOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), testing(3), operational(4), resetInProgress(5), warning(6), nonFatalError(7), fatalError(8), loading(10) } ACCESS read-only STATUS mandatory DESCRIPTION " Provides operational status of the entity. The following are possible definitions of the values. The exact definition of the values is implementation specific. A value of other(1) implies some undetermined state, possibly as a result of setting chasEntityAdminStatus to a value of disable(3). A value of invalid(2) could have the possible meaning that the entity exists but the chassis manager has no direct control of the entity. A value of testing(3) may be a diagnostic state. A value of operational(4) implies that the entity is running with no errors or warnings. State resetInProgress(5) implies equivalent of setting chasEntityAdminStatus to reset(4). The states of warning(6), nonFatalError(7), fatalError(8) reflect conditions detected during operation. The entity may or may not be still functional. State loading(10) is a result of asserting programload(5) in chasEntityAdminStatus. For example if an entities value of chasEntityAdminStatus is disable(3) and is set to enable(2) then chasEntityOperStatus may enter a state of testing(3) then change to a value of operational(4)." ::= { chasEntityEntry 7 } -- chasEntityArgument OBJECT-TYPE -- REMOVED -- Too implementation specific. This was decided I believe at the -- Washington IETF. chasEntityTimeStamp OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of MIB-II's sysUpTime (in the agent supporting this MIB) at which this entity was last (re-)initialized. If the entity has not been initialized then this object has a zero value." ::= { chasEntityEntry 9 } chasEntityTargetParty OBJECT-TYPE SYNTAX Party ACCESS read-only STATUS mandatory DESCRIPTION " Access to the detailed management information for an entity is provided using one of a number of techniques. For this object I assume for the present that the 'Party Reformation Act' is accepted. This area needs to be revistited if that proposal is rejected. Firstly the agent providing detailed information for this object may be running SNMPv1. In this case there is NO target party and this object will not exist for such a row. Secondly SNMPv2 is being run on the chassis agent and the entity agent is co-resident with that agent. In this case the target party defines the party to be used to access management information about this entity. The party exists at the same transport address as the chassis agent and so the entityTAddress object will not exist for this row. Note that the destination parties define access policy, not the target party so there only needs to be a single target party for all privileges. To determine which destination parties provide access to this target interrogate the SNMPv2 aclTable for entries with this party as the same target. Next the agent for the entity may be entirely at a separate transport address. If the agent at that address deals directly with this entity then there will be no target party and so this object will not exist. Access to the detailed view of the entity is provided in the same way as for a simple device. The entityTAddress identifies where the agent for the entity resides. Finally the agent for the entity is resident at a separate transport address and the agent at that address actually provides proxy access to the entity. In this case the entityTAddress provides the address at which to use this target party." ::= { chasEntityEntry 10 } chasEntityCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) ACCESS read-only STATUS mandatory DESCRIPTION " If the agent which implements the detailed view of this agent is resident at the same transport address as the chassis agent, and the agent is using SNMPv1, this object provides a community string that must be used to access the correct view of the MIB. Note that in this model only one view of the device is provided. There is no provision when using SNMPv1 with this MIB to define a read-only and a read-write view of the entity! If a community string is NOT required to access this entity then this object will not exist for this row of the table." ::= { chasEntityEntry 11 } chasEntityTDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION " If the agent which provides detailed access to the management information for this entity does not execute at this transport address this object will exist. If this object exists then it identifies the transport domain in which the agent for this entity executes. An example of a transport domain is rfc1351Domain (SNMP over UDP)" ::= { chasEntityEntry 12 } chasEntityTAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION " If the agent which provides detailed access to the management information for this entity does not execute at this transport address this object will exist. If this object exists then it identifies the address at which the agent exists." ::= { chasEntityEntry 13 } chasEntityRowStatus OBJECT-TYPE SYNTAX RowStatus ACCESS read-write STATUS mandatory DESCRIPTION " A manager may attempt to create new instances of 'entity' within this chassis. Depending on the capabilities and design of the chassis none, some or all types of entity may be created. To attempt to create a new entity the following procedure should be followed: Locate an empty row in the entity table Set Row Status for that row to underConstruction If this fails then this chassis does not support entity creation Write the type of the desired entity to chasEntityType If this fails then there is insufficient resources available to create an entity of that type. For example trying to create certain types of entities is likely to always fail (ie creating a power supply) If this works the row status will automatically change to active and the new entity is available for the assignment of components. To delete an entity set the row status to underDestruction. If the entity can be deleted then the row representing this entity will immediately dissappear. Note that all components assigned to this entity will become unassigned and available for use in other entities." DEFVAL underCreation ::= { chasEntityEntry 14 } -- componentTable OBJECT-TYPE SYNTAX SEQUENCE OF ComponentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " Each physical module contains a number of logical components. Each logical component is a building block for constructing functional entities. This table contains an entry for each component in the chassis, the type of entity this component can belong to and the current entity to which this component is assigned." ::= { chasComponent 1 } componentEntry OBJECT-TYPE SYNTAX ComponentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " This entry describes one logical component in the chassis at a particular instant. Note that if the physical module on which this component resides is removed from the chassis then this entry in the table will b destroyed. Components may not be created or destroyed but can be assigned to different entities in the system. Each entry in the table is identified by it physical location (type and position) and by a component index to distinguish between different components at the same location. Note that the first two index values are borrowed from/shared with other tables in this MIB." INDEX {locationTypeIndex, phyLocation, compIndex} ::= { componentTable 1 } ComponentTable ::= SEQUENCE { compIndex INTEGER, compEntityType OBJECT IDENTIFIER compEntityAssignment INTEGER } compIndex OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS mandatory DESCRIPTION " Each physical module in the chassis comprises a number of distinct logical components. The compIndex allows unique identification of each of the components within a particular module." ::= { componentEntry 1 } compEntityType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION " Each component in a module may be assigned to a particular entity type. This column defines a single value of chasEntityType. The column basically gives information to the managemet station to say 'this componnt may only be assigned to entities with chasEntityType equal to this objects value'. It is a hint really to the application. The value in this column does not prevent someone trying to assign, say, an 802.3 repeater port to a token ring entity but gives advanced information that such a request will fail. If the agent does not wish to restrict assignment of this component to entities of a particular type this object should be set to the null object identifier." ::= { componentEntry 2 } compEntityAssignment OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION " Each component in the current physical configuration of the chassis is present in this table. Most of those components will be assigned to a particular entity. This object identifies the current assignment of this component. The value of this object is the value of chasEntityIndex of the entity to which this component is currently assigned. If a component is not currently assigned to an entity this object will have the value of zero. A manager may write a new entity value to this object. If the entity accepts assignment of this component then the component is removed from any old entity and assigned to the new entity. If an attempt is made to assign this component to an inappropriate entity, for example an 802.3 repeater port to a token ring entity, that request will fail and the compEntityAssignment will contain its old value. If zero is written to this object then that component is removed from its current assignment and is not assigned to any other entity. The behaviour of an unassigned component is specific to that implementation. Examples of valid implementation behaviour would be: Unassigned repeater component: Do nothing. Unassigned bridge port: Connect to external port." ::= { componentEntry 3 } -- TRAPs -- These need to be defined. Use SNMPv1 or SNMPv2? -- Traps should be generated for the following situations: -- Module removed from chassis -- Module added to chassis repeater8023 OBJECT IDENTIFIER ::= { chasKnownTypes 1 } tokenRing8025 OBJECT IDENTIFIER ::= { chasKnownTypes 2 } fddiRing OBJECT IDENTIFIER ::= { chasKnownTypes 3 } bridge OBJECT IDENTIFIER ::= { chasKnownTypes 4 } router OBJECT IDENTIFIER ::= { chasKnownTypes 5 } brouter OBJECT IDENTIFIER ::= { chasKnownTypes 6 } terminalServer OBJECT IDENTIFIER ::= { chasKnownTypes 7 } chassis OBJECT IDENTIFIER ::= { chasKnownTypes 8 } powerSupply OBJECT IDENTIFIER ::= { chasKnownTypes 9 } networkMonitor OBJECT IDENTIFIER ::= { chasKnownTypes 10 } chassisFan OBJECT IDENTIFIER ::= { chasKnownTypes 11 } displayPanel OBJECT IDENTIFIER ::= { chasKnownTypes 12 } networkDeviceSlot OBJECT IDENTIFIER ::= { chasKnownLocations 1 } powerSupplyBay OBJECT IDENTIFIER ::= { chasKnownLocations 2 } fanPosition OBJECT IDENTIFIER ::= { chasKnownLocations 3 } backplanePosition OBJECT IDENTIFIER ::= { chasKnownLocations 4 } -- Complete Example -- ---------------------- The following chassis is now described in terms of the tables in the MIB shown above. module type location description ----------------------------------------------------------------- powerSupplyBay 1 PSU 1 powerSupplyBay 2 PSU 2 networkDeviceSlot 1 802.3 Switch Rptr Line Card (4 port) networkDeviceSlot 2 802.3 Switch Rptr Line Card (4 port) networkDeviceSlot 3 802.3 Switch Rptr Line Card (4 port) networkDeviceSlot 4 802.3 Switch Rptr Line Card (4 port) networkDeviceSlot 5 802.3 Bridge Card (3 port) networkDeviceSlot 6 Empty backplane 1 Ethernetx3 Backplane The components contained on each module are as follows: PSU 1 comprises 5V dc supply 12V dc supply PSU 2 comprises 5V dc supply 12V dc supply Each 802.3 Rptr Line Card 4x Repeater Port, each switchable to any backplane. 802.3 Bridge Card Port 1, Port 2, Port 3, Bridge Comp Backplane Ether1, Ether2, Ether3 At a particular time these components are configured to provide 3 repeaters. Two of the repeaters are bridged together using two of the 802.3 bridge ports. The third bridge port provides an external backbone connection: Repeater 1: Slot 1, Port 1..4 Repeater 2: Slot 2, Port 1..4 Slot 3, Port 1..2 Ether1 Repeater 3: Slot 3, Port 3..4 Ether2 Bridge Port 1: Connects to Repeater 2 Bridge Port 2: Connects to Repeater 3 Bridge Port 3: External backbone connection --------------------------------------------------------------------------- The proposed MIB would represent this chassis configuration in the following way: phyLocationTable: ----------------- Type(networkDeviceSlot) Count(6) Name("Network Slot") Type(powerSupplyBay) Count(2) Name("Power Supply") Type(backplanePostition) Count(1) Name("Backplane") phyConfigTable: (partial) --------------- networkDeviceSlot.1 Conents(rptrCard) Desc("802.3 Repeater Card") OperStat(Operational) networkDeviceSlot.2 Conents(rptrCard) Desc("802.3 Repeater Card") OperStat(Operational) networkDeviceSlot.3 Conents(rptrCard) Desc("802.3 Repeater Card") OperStat(Operational) networkDeviceSlot.4 Conents(rptrCard) Desc("802.3 Repeater Card") OperStat(Operational) powerSupplyBay.1 Conents(PSU) Desc("PSU") OperStat(Operational) powerSupplyBay.2 Conents(PSU) Desc("PSU") OperStat(Operational) backplanePosition.1 Conents(EtherBackplane) Desc("Ethernet Backplane") OperStat(Operational) The other columns in the phy config table provide information concerning a particular module, eg version numbers etc. This information is not shown. -------------------------------------------------------------------------- charEntityTable --------------- Index(1) repeater8023 "802.3 Repeater 1" targetParty(xyz.1.1) RowStatus(active) Index(2) repeater8023 "802.3 Repeater 2" targetParty(xyz.1.2) RowStatus(active) Index(3) repeater8023 "802.3 Repeater 3" targetParty(xyz.1.3) RowStatus(active) Index(4) bridge "802.3x3 Bridge Module 1" TAddress(123.234.12.23.0.161) RowStatus(active) (Bridge has it's own SNMP stack) Index(5) powerSupply "5V Power Supply" No access information, implying part of same device as chassis MIB Index(6) powerSupply "12V Power Supply" No access information, implying part of same device as chassis MIB -------------------------------------------------------------- >From the above table we know which modules exist and which entities exist but there is no knowledge of how those entities are implemented. This is provided by: componentTable -------------- networkDeviceSlot.1.1 Type(repeater8023) Assignment(1) networkDeviceSlot.1.2 Type(repeater8023) Assignment(1) networkDeviceSlot.1.3 Type(repeater8023) Assignment(1) networkDeviceSlot.1.4 Type(repeater8023) Assignment(1) networkDeviceSlot.2.1 Type(repeater8023) Assignment(2) networkDeviceSlot.2.2 Type(repeater8023) Assignment(2) networkDeviceSlot.2.3 Type(repeater8023) Assignment(2) networkDeviceSlot.2.4 Type(repeater8023) Assignment(2) networkDeviceSlot.3.1 Type(repeater8023) Assignment(2) networkDeviceSlot.3.2 Type(repeater8023) Assignment(2) networkDeviceSlot.3.3 Type(repeater8023) Assignment(3) networkDeviceSlot.3.4 Type(repeater8023) Assignment(3) networkDeviceSlot.4.1 Type(repeater8023) Assignment(0) networkDeviceSlot.4.2 Type(repeater8023) Assignment(0) networkDeviceSlot.4.3 Type(repeater8023) Assignment(0) networkDeviceSlot.4.4 Type(repeater8023) Assignment(0) networkDeviceSlot.5.1 Type(repeater8023) Assignment(2) networkDeviceSlot.5.2 Type(repeater8023) Assignment(3) networkDeviceSlot.5.3 Type(repeater8023) Assignment(0) networkDeviceSlot.5.4 Type(bridge) Assignment(4) powerSupplyBay.1.1 Type(powerSupply) Assignment(5) powerSupplyBay.1.2 Type(powerSupply) Assignment(6) powerSupplyBay.2.1 Type(powerSupply) Assignment(5) powerSupplyBay.2.2 Type(powerSupply) Assignment(6) backplanePosition.1.1 Type(repeater8023) Assignment(2) backplanePosition.1.2 Type(repeater8023) Assignment(3) backplanePosition.1.3 Type(repeater8023) Assignment(0) NOTE: All ports on module in slot 4 are currently unused. Behaviour unknown. Third bridge port currently not assigned to an entity and so behaviour is unknown. In this case the behaviour is to connect to an external port. This information is in the domain of the bridge manager. Backplane Ethernet 3 is also currently unused. -------------------------------------------------------------------------- Suppose we wish to create a new repeater using the un-assigned ports on card 4. The following sequence would achieve this: write entityTable.RowStatus.7, underCreation No errors for this example write entityTable.chasEntityType.7, repeater8023 No errors for this example -- Entity now exists. Assign Components. write componentTable.compEntityAssignment.networkDeviceSlot.4.1, 7 write componentTable.compEntityAssignment.networkDeviceSlot.4.2, 7 write componentTable.compEntityAssignment.networkDeviceSlot.4.3, 7 write componentTable.compEntityAssignment.networkDeviceSlot.4.4, 7 Now to use the current external bridge port to bridge this repeater instead of it's current assignment it is necessary to assign a backplane then assign the bridge. write componentTable.compEntityAssignment.backplanePosition.1.3, 7 write componentTable.compEntityAssignment.networkDeviceSlot.5.3, 7 NOTE 1: Quite a number of the objects in the tables described above will be configured due to hardware and design decisions. For example the configuration of power supplies etc. NOTE 2: In the example I've used the explicit backplane assignment system described earlier. This is to illustrate more clearly how the backplane segments are now handled. In many ways the implicit handling of backplanes would be better.
- [peterw@pdd.3com.com: Chassis MIB Proposal] Bob Stewart