Pete's Chassis MIB - Assembled

musher@ccrelay.fibermux.com Fri, 07 January 1994 23:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16153; 7 Jan 94 18:30 EST
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa16149; 7 Jan 94 18:30 EST
Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id RAA24232; Fri, 7 Jan 1994 17:58:25 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 7 Jan 1994 17:58:23 EST
Errors-to: owner-chassismib@CS.UTK.EDU
Received: from uu.psi.com by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id RAA24212; Fri, 7 Jan 1994 17:57:39 -0500
Received: from fibermux.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP; id AA06783 for ; Fri, 7 Jan 94 17:35:19 -0500
Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1) id AA06099; Fri, 7 Jan 94 13:08:43 PST
Received: from ccMail by ccrelay.fibermux.com id AA757976888 Fri, 07 Jan 94 13:08:08 PST
Date: Fri, 07 Jan 94 13:08:08 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: musher@ccrelay.fibermux.com
Encoding: 68654 HEX
Message-Id: <9400077579.AA757976888@ccrelay.fibermux.com>
To: chassismib@cs.utk.edu
Subject: Pete's Chassis MIB - Assembled

From: <{3COM/PDD/PeteW}@PDD.3Mail.3Com.COM> at ccrelayout 1/4/94 9:39AM
Subject: Chassis MIB proposal
------------------------------------------------------------------------------

Dan,
I already updated my chassis MIB proposal last October and sent it to the 
chassis MIB mailing list. There was very little (no) interest at that point 
although activity in most other management related working groups had died 
down. There is a real need for a chassis MIB, but the problem is complex and 
I'm not convinced there is a will to find a solution at this stage. I'll 
resend my complete proposal to the chassis MIB mailing list (it might end up 
UUENCODED due to our Microsoft Mail gateway!)

Pete



Below is my proposal, resent from last October, for a complete chassis MIB 
proposal.
==============================
I've spent some time going over the chassis MIB drafts trying to pull
together all the strands into a single MIB and to provide some
descriptive text. This is the result.

What I've done:
- Taken the most stable and discussed chassis MIB draft.
- Modified the power supply and sensor groups to be consistent with the
  modified model.
- Added an optional link table that can be used to describe the
  physical interconnection of elements in the chassis (without
  overloading the inventory tables).

There seemed to be quite a lot of interest in this MIB when the WG was being
disbanded, but very little since. I'd appreciate those of you
interested in the MIB at that time reading this proposal and returning
comments to myself. I will be at the November IETF meeting if you
would like to discuss any of this in person.

thanks
Pete
----------------------------------------------------------------------------
Definitions/Glossary
====================
Chassis:      A generic 'container'. Specifically for the purpose of this MIB
              implement network devices. A chassis can be viewed either from
              physical or logical perspective. Physically a chassis contains
              a number of modules. Logically a chassis contains a collection
              of functional 'entities'.

Module:       A module is a physical thing contained within a chassis. A
              particular chassis can contain any number of different types
              of module and any number of distinct instances of the same
              type of module. A module is distinguished from other modules
              in a chassis by its type and its position within the chassis.
              A module is itself a container of 'resources'.

Resource:     Each physical module comprises a number of resources. The
              resources can be of any kind, for example a repeater port,
              bridge relay etc.

Entity:       An entity is a functional unit within the chassis. An 'entity'
              is analogous to a seperate, standalone device. Examples of
              chassis entities are: Ethernet repeaters, bridges, routers,
              token ring concentrators.

Link:         A Link is a description of a known connection between two
              resources in the chassis. A particular chassis can describe
              its internal topological configuration by entries in a table
              of links in the MIB. Note that it is not necessary to
              describe all links in the chassis, only those that are useful.
              Refer to the MIB group descriptions for an example of
              how links can be used to describe mappings of multiple bridges
              and routers to the same physical network connections (the
              'brouter' scenario).

The Model
=========

For the purposes of this MIB a chassis is any device, or collection of
devices that together can be considered a single entity. For example,
traditional multi-slot 19" rack mounting chassis are included, as are the
newer stackable type devices. The MIB is not limited to such devices and so
could be used to describe any containment type of relationship. Note that if
necessary an instance of the 'chassis' could logically contain a sub chassis
to allow an arbitrarily deep containment hierarchy.

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, or location. Each type of location is specialised to hold a
particular type of item or module.  Examples of compartment types would be
network card slots, power supply bays and fan trays.  At any instant in time
each location in a chassis 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 Ethernet repeaters, bridges, routers
and terminal servers.

An entity is implemented using parts from one or more of the physical
modules in the chassis. 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, or
resources. A number of these resources 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
resource from which project teams are constructed. Each person is
specialised for a particular role within a project.

Floor       Function:Person     Project         Implemented By
(module)      (resource)        (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 resources 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 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 resource of all cards visible and allow the configuration of those
resources 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

Combining Resources 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 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

agtegy 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 resources 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 resources assigned to that entity may
differ.
----------------------------------------------------------------------------
CHASSIS-MIB DEFINITIONS ::= BEGIN

IMPORTS
    OBJECT-TYPE
        FROM RFC-1212
    experimental, TimeTicks, IpAddress, Counter
        FROM RFC1155-SMI

-- Textual Conventions

DisplayString ::= OCTET STRING
-- This data type is used to model textual information taken
-- from the NVT ASCII character set.  By convention, objects
-- with this syntax are declared as having
--
--      SIZE (0..255)

Context       ::= OBJECT IDENTIFIER
-- This is a definition used to identify SNMPv2 'Contexts' used to
-- represent views of different entities.

TAddress      ::= OCTET STRING
-- Used to represent generic 'transport' addressing mechanisms. The
-- protocol type determines how this address is interpreted. This is
-- an SNMPv2 textual convention.

chassis             OBJECT IDENTIFIER ::= { experimental 38 }

-- Groups within the chassis MIB

chasInfo            OBJECT IDENTIFIER ::= { chassis 1 }
chasPhysical        OBJECT IDENTIFIER ::= { chassis 2 }
chasEntity          OBJECT IDENTIFIER ::= { chassis 3 }
chasResource        OBJECT IDENTIFIER ::= { chassis 4 }
chasPowerSupply     OBJECT IDENTIFIER ::= { chassis 5 }
chasEnviron         OBJECT IDENTIFIER ::= { chassis 6 }

-- Chassis MIB Known Types
chasKnownTypes      OBJECT IDENTIFIER ::= { chassis 7 }

-- Values for known chasPhyLocationType. The types of
--    location in the chassis.

chasLocationTypes   OBJECT IDENTIFIER ::= { chasKnownTypes 1 }

chasModularSlot     OBJECT IDENTIFIER ::= { chasLocationTypes 1 }
chasPowerSupplyBay  OBJECT IDENTIFIER ::= { chasLocationTypes 2 }
chasFanTray         OBJECT IDENTIFIER ::= { chasLocationTypes 3 }
chasBackplane       OBJECT IDENTIFIER ::= { chasLocationTypes 4 }
chasFrontSlot       OBJECT IDENTIFIER ::= { chasLocationTypes 5 }
chasBackSlot        OBJECT IDENTIFIER ::= { chasLocationTypes 6 }

-- Values for chasModuleType.

chasModuleTypes     OBJECT IDENTIFIER ::= { chasKnownTypes 2 }
chasLocationEmpty   OBJECT IDENTIFIER ::= { chasModuleTypes 1 }
chasModuleUnknown   OBJECT IDENTIFIER ::= { chasModuleTypes 2 }

-- Values for chasEntityObjectId.

chasEntityTypes  OBJECT IDENTIFIER ::= { chasKnownTypes 3 }

-- Chassis components non-networking

chasChassisEntities OBJECT IDENTIFIER ::= { chasEntityTypes 1 }

chasPowerSupplyModule  OBJECT IDENTIFIER ::= { chasChassisEntities  1 }
chasChassis            OBJECT IDENTIFIER ::= { chasChassisEntities  2 }
chasMonitors           OBJECT IDENTIFIER ::= { chasChassisEntities  3 }

-- Basic Network Entities

chasNetEntities OBJECT IDENTIFIER ::= { chasEntityTypes 2 }

chas8023Repeater OBJECT IDENTIFIER ::= { chasNetEntities 1 }
chas8025Ring     OBJECT IDENTIFIER ::= { chasNetEntities 2 }
chasFddiRing     OBJECT IDENTIFIER ::= { chasNetEntities 3 }
chasAtmSwitch    OBJECT IDENTIFIER ::= { chasNetEntities 4 }
chasFrameRelay   OBJECT IDENTIFIER ::= { chasNetEntities 5 }

-- Internetworking/Bridging

chasConnectEntities OBJECT IDENTIFIER ::= { chasEntityTypes 3 }
chasBridge          OBJECT IDENTIFIER ::= { chasConnectEntities 1 }
chasRouter          OBJECT IDENTIFIER ::= { chasConnectEntities 2 }
chasBrouter         OBJECT IDENTIFIER ::= { chasConnectEntities 3 }
chasGateway         OBJECT IDENTIFIER ::= { chasConnectEntities 4 }
chasSwitch          OBJECT IDENTIFIER ::= { chasConnectEntities 5 }

--  Values for chasPhyResType.

chasResTypes  OBJECT IDENTIFIER ::= { chasKnownTypes 4 }

--  Chassis type resources.

chasChassisRes OBJECT IDENTIFIER ::= { chasResTypes 1 }

--  Basic Network Resource

chasNetworkRes OBJECT IDENTIFIER ::= { chasResTypes 2 }

chas8023RptrPort  OBJECT IDENTIFIER ::= { chasNetworkRes 1 }
chas8025MauPort   OBJECT IDENTIFIER ::= { chasNetworkRes 2 }
chasFddiPort      OBJECT IDENTIFIER ::= { chasNetworkRes 3 }
chasAtmPort       OBJECT IDENTIFIER ::= { chasNetworkRes 4 }
chas8023PortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 5 }
chas8025PortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 6 }
chasFddiPortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 7 }
chasAtmPortGroup  OBJECT IDENTIFIER ::= { chasNetworkRes 8 }

-- Backplane Network Resources (if required)

chasBplaneRes  OBJECT IDENTIFIER ::= { chasResTypes 3 }

chas8023Bplane    OBJECT IDENTIFIER ::= { chasBplaneRes  1 }
chas8025Bplane    OBJECT IDENTIFIER ::= { chasBplaneRes  2 }
chasFddiBplane    OBJECT IDENTIFIER ::= { chasBplaneRes  3 }
chasMgmtBplane    OBJECT IDENTIFIER ::= { chasBplaneRes  4 }
chasAtmBplane     OBJECT IDENTIFIER ::= { chasBplaneRes  5 }

-- Internetworking/bridging resources (if required)

chasConnectRes OBJECT IDENTIFIER ::= { chasResTypes 4 }

chasBridgeRelay   OBJECT IDENTIFIER ::= { chasConnectRes 1 }
chasRouterRelay   OBJECT IDENTIFIER ::= { chasConnectRes 2 }
chasBrouterRelay  OBJECT IDENTIFIER ::= { chasConnectRes 3 }
chasSwitchMatrix  OBJECT IDENTIFIER ::= { chasConnectRes 4 }

-- Finally a value that can be used anywhere that an OID type identifier
-- is required, but the definitive value is unknown.
chasTypeUnknown     OBJECT IDENTIFIER ::= { chassis 8 }

-- chasInfo group (chassis information group).
-- Implementation of this group is mandatory.

chasType  OBJECT-TYPE
    SYNTAX  OBJECT IDENTIFIER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
            "An authoritative identification of the type of
            hub-based or standalone chassis.  By convention
            this value is allocated within the SMI enterprises
            subtree(1.3.6.1.4.1), and provides an easy and
            unambiguous means for determining `what kind of
            box' is being managed.  If this information is not
            present or unknown, its value should be set to the
            value: chasTypeUnknown.

            Note that the value of this object is not the same as the
            value of sysObjId. sysObjId refers to the product running
            the agent and NOT the chassis itself. Eg there could be
            several variants of a management card for a single chassis."
    ::= { chasInfo 1 }

-- && chasPhysicalChanges: Removed. Definition is too vague and the use
-- && is unclear. Does it include moving a resource from one entity to
-- && another?

chasChassisSerialNumber   OBJECT-TYPE
    SYNTAX    DisplayString (SIZE (0..32))
    ACCESS    read-only
    STATUS    mandatory
    DESCRIPTION
        "The serial number of the chassis. If no serial
         number is available then this object should be the
         zero length string."
    ::= { chasInfo 2 }

-- chasPhysical group (physical configuration group).
-- Implementation of this group is mandatory.

chasPhyLocationTable OBJECT-TYPE
    SYNTAX SEQUENCE OF ChasPhyLocationEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "This table summarises the different classes of
         and types of modular physical locations in the
         chassis.  This includes but is not limited to slots
         within a chassis, power supply bays and fan tray slots.

         Note that entries in this table cannot be created or
         deleted through external management."
    ::= { chasPhysical 1 }

chasPhyLocationEntry OBJECT-TYPE
    SYNTAX ChasPhyLocationEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
            "An entry in the phyLocationTable"
    INDEX { chasPhyLocationTypeIndex }
    ::= { chasPhyLocationTable 1 }

ChasPhyLocationEntry ::= SEQUENCE {
    chasPhyLocationTypeIndex        INTEGER,
    chasPhyLocationCount            INTEGER,
    chasPhyLocationType             OBJECT IDENTIFIER,
    chasPhyLocationName             DisplayString
}

chasPhyLocationTypeIndex OBJECT-TYPE
    SYNTAX INTEGER (1..65535)
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
       "This uniquely identifies the physical location
        type within the chassis."
    ::= { chasPhyLocationEntry 1 }

chasPhyLocationCount  OBJECT-TYPE
    SYNTAX INTEGER (1..65535)
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Each physical location exists one or more times.
         This object defines the number of instances that
         exist for the specified location type."
    ::= { chasPhyLocationEntry 2 }

chasPhyLocationType OBJECT-TYPE
    SYNTAX OBJECT IDENTIFIER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Uniquely identifies the 'type' of the physical
         location within the chassis."
    ::= { chasPhyLocationEntry 3 }

chasPhyLocationDescr OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Each type of physical location within the chassis
         is given a textual name."
    ::= { phyLocationEntry 4 }


chasModuleTable OBJECT-TYPE
    SYNTAX SEQUENCE OF ChasModuleEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "This table identifies the physical modules within the
         chassis. Each module is identified by means of its
         location within the chassis, as specified by reference
         to chasPhyLocationTable.

         If a location is empty then a particular implementation of
         this MIB may choose to include or exclude a row representing
         that location. If an implementation chooses to include a row
         for every location, then those rows representing empty slots
         will be identified by a value for chasModuleType of
         chasLocationEmpty."
    :: { chasPhysical 2 }

chasModuleEntry OBJECT-TYPE
    SYNTAX ChasPhyModuleEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "An entry in this table that describes a physical
         module that is currently present at a given physcial
         location within the chassis."
    INDEX { chasModuleLocationType, chasModuleLocation }
    ::= { chasModuleTable 1 }

ChasPhyModuleEntry ::= SEQUENCE
    chasModuleLocationType        INTEGER,
    chasModuleLocation            INTEGER,
    chasModuleType                OBJECT IDENTIFIER,
    chasModuleSwVersion           DisplayString,
    chasModuleHwVersion           DisplayString,
    chasModuleSerialNumber        DisplayString,
    chasModuleDescription         DisplayString,
    chasModuleLastChange          TimeTicks,
    chasModuleState               INTEGER
}

chasModuleLocationType  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "An instance of a module is identified by the
         physical location in which it resides.  The physical
         location is identified by location type and
         location index (instance of that location type).
         This value of this object identifies a row in the
         the chasPhyLocationTable, ie a value of
         chasPhyLocationTypeIndex."
    ::= { chasModuleEntry 1 }

chasModuleLocation  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "An instance of a module is identified by the
         physical location in which it resides.  The physical
         location is identified by location type and
         location index (instance of that location type).
         This object defines the instance of a particular
         location type.  It must be within the bounds
         defined by chasPhyLocationCount for the conceptual
         row in the chasPhyLocationTable identified by
         chasModuleLocationType."
    ::= { chasModuleEntry 2 }

chasModuleType OBJECT-TYPE
    SYNTAX OBJECT IDENTIFIER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "An authoritative identification of the type of
         physcial module in this physical location.  A
         value of chasModuleUnknown indicates that the type
         of physical module is unknown.

         A particular implementation of this MIB may be such that it
         contains an entry for every location in the chassis, including
         those that are empty. In such cases the value of this object
         for locations that are empty should be chasLocationEmpty."
    :== { chasModuleEntry 3 }

chasModuleSwVersion OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..32))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A textual description of the version/revision
         level for this module's software.  If not applicable
         or the location represented by this row is empty then
         the value of this object should be a zero-length
         string."
    :== { chasModuleEntry 4 }

chasModuleHwVersion OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..32))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A textual description of the version/revision
         level for this module's firmware.  If not available
         or the location represented by this row is empty then
         the value of this object should be a zero-length string."
    ::= { chasModuleEntry 5 }

chasModuleSerialNumber OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..32))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The serial number of the physical module present
         in this physical location. If no serial number is
         available for a particular row, or that row represents
         an empty location then the value of this object should be
         a zero length string."
    ::= { chasModuleEntry 6 }

chasModuleDescription OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..32))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
            "A textual description of the physical module
            plugged that resides in this physical location.

            If not available for a particular row, or that row
            represents an empty location then the value of this
            object should be a zero length string."
    ::= { chasModuleEntry 7 }

chasModuleLastChange 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 or initialized.  If the module has
             not changed since the last network managment
             system reinitialized, or a particular row represents
             an empty slot then the value of this object will be
             zero."
    ::= { chasModuleEntry 8 }

-- && Replaced chasModuleAdminStatus and chasModuleOperStatus with
-- && chasModuleState. It was unclear what value should be returned when
-- && reading the value of the Admin state and write-only parameters are
-- && no longer in vogue.
-- &&
-- && A state table for this object will be included in the text to this MIB

chasModuleState OBJECT-TYPE
    Syntax INTEGER {
        other               (1),

        enable              (2),
        disable             (3),
        reset               (4),
        test                (5),

        testInProgress      (6),
        resetInProgress     (7),
        operational         (8),
        diabled             (9),
        warning            (10),
        nonFatalError      (11),
        fatalError         (12)
    }
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
       "This object may be read or written. Reading the value of this
        object returns the current state of the module, writing to this object
        requests a change in state of this module. The values enable(2),
        disable (3), reset (4) and test (5) are writable values. All other
        values are readable states. An SNMP error will occur on an attempt
        to write a any value other than one of the four above.

        It is not a requirement that all chassis support all read or write
        values, or that a single chassis support the same set of writable
        values for all modules. It may be inappropriate to support 'reset'

     for a power supply module! Writing an unsupported value to a
        particular instance of this object will return an SNMP error.

        The writable values for this object are:

           enable(2). An enabled module contains resources that are, or
           may be, part of entities within the chassis. If a disabled module
           is successfully enabled its state will change to operational(8).

           disable(3). If a module is disabled then it acts as though it
           were unpowered. A disabled module has no resources in the
           resource table. Disabling a module has the side-effect that all
           resources on that module are removed from the resource tables.

           Writing a value of reset(3) simulates a power-on reset sequence.
           It is not necessary to change the contents of the resource tables
           for the duration of the reset. Note: the module being reset could
           be that module on which this instance of the chassis MIB is
           running; reset is a transitory state. For the duration of the
           reset the module will enter a resetInProgrss(7) state.
           It is not a requirement that after a module is reset that it should
           enter the same state in which it existed before the reset.

           Writing a value of test(4) will start a self test sequence
           on the module. While the card is being tested the value
           of this object will be testInProgress(6).

        The readable values are:

           testInProgress (6). This is a transitory state that the card in
           which the module will exist during tests.

           resetInProgress (7). The chassis is currently being reset.

           operational (8). The module is fully operational. The resources
           on this module are represented in the resource table and may be
           participating in the implementation of entities in the chassis.

           diabled (9). The module has been disabled.

           warning (10). The module is operational but a minor error has
           been detected by the card.

           nonFatalError (11). The module is operational but a non-fatal
           error has been detected. The card is still participating in the
           inplementation of entities within the chassis, but it may not
           be functioning completely.

           fatalError (12). The card has detected a fatal error and is
           no longer active."
    ::= { chasModuleEntry 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 (entities) in this
             chassis."
    ::= { chasEntity 1 }

chasEntityEntry OBJECT-TYPE
    SYNTAX  ChasEntityEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
        "Information concerning an entity in the chassis. Rows may be
         created and deleted from this table as different chassis
         configurations are required. The table uses the SNMPv2 RowStatus
         type semantics for row control. The RowStatus type is NOT used
         in order to maintain compatibility with SNMPv1.

         To create a new entity in this chassis, first create a row in this
         table to represent that entity, then 'assign' resources to this
         entity to build the required configuration.

         If an entity is deleted from this table the resources that were part
         of that entity become 'floating' until they once again are assigned
         to an entity."
    INDEX  { chasEntityIndex }
    ::= { chasEntityTable 1 }

-- && Note that the chasEntityAdminStatus and chasEntityOperStatus objects
-- && have been removed. Control of an entity as a whole is in the domain
-- && of the management view of that entity and is outside of the scope of the
-- && chassis MIB.
-- &&
-- && This is NOT the case with the module state because that deals with
-- && the physical modules of the chassis, which are hidden from the
-- && specific management view of the entity.
ChasEntityEntry ::=
    SEQUENCE {
        chasEntityIndex            INTEGER,
        chasEntityObjectID         OBJECT IDENTIFIER,
        chasEntityDescr            DisplayString,
        chasEntityTimeStamp        TimeTicks,
        chasEntityRowStatus        INTEGER
    }

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 }

chasEntityObjectID  OBJECT-TYPE
    SYNTAX  OBJECT IDENTIFIER
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "The specific type of entity. A value for this column MUST be
         specified when creating a row."
    ::= { chasEntityEntry 2 }

chasEntityDescr  OBJECT-TYPE
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A textual description of the entity. This string will be
         generated by the agent."
    ::= { chasEntityEntry 3 }

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 4 }

chasEntityRowStatus  OBJECT-TYPE
    SYNTAX  INTEGER {
               -- The following two values are states:
               -- these values may be read or written.
               active             (1),
               notInService       (2),

               -- the following value is a state:
               -- this value may be read but not written.
               notReady           (3),

               -- the following three values are actions:
               -- these values may be written, but not read.
               createAndGo        (4),
               createAndWait      (5),
               destroy            (6)
           }
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "To create a row in this table the following procedure should
         be applies:
           1. Find an unused index in the table.
           2. In one packet write a value for chasEntityObjectID and
              chasEntityRowStatus to createAndGo

                          OR

           1. Find an unused index in the table.
           2. Set chasEntityRowStatus to createAndWait, this will
              result in the value of chasEntityRowStatus becoming notReady.
              After this step the value of chasEntityObjectID will be {0.0}.
           3. Set the value of chasEntityObjectID to identify the required
              entity type. An attempt to write an illegal, unsupported or
              inappropriate value to this object will result in an SNMP
              error and the value remaining unchanged.
           4. Set the chasEntityRowStatus to 'active'.

         Note that there are a number of reasons why the may refuse to
         create an entity:
           a) The particular chassis does NOT permit the creation and deletion
              of entities through management operation. An attempt to create
              a row in this table with such an agent will result in an SNMP
              error.
           b) The chassis does not permit the creation of the specified type
              of entity. For example an attempt to create a fan! If method 1)
              is used to create the row the state of the row will remain
              notReady.
           c) The chassis insufficient resource to create any additional
              entities. The attempt to create a row under these conditions wil
l
              return an SNMP error."
    ::= { chasEntityEntry 5 }


-- The chasEntityViewTable is used to provide access to the various MIB
-- views of the different entities in the chassis. Note that this table
-- must allow an SNMPv1 implementation of the chassis agent to point to an
-- entity accessed via a different SNMPv2 agent. This is particularly true
-- while SNMPv2 is yet to become an established protocol.
--
-- && Another constraint on this table is that it must allow the SNMP protocol
-- && to be carried over various transport domains. For this reason the intern
et
-- && draft version of this table was inadequate.
--
-- && I don't really like this table at all for the following reasons:
-- && a) It is adequate to identify different views for SNMPv1 but does
-- &&    not adequately identify SNMPv2 access.
-- && b) Even for SNMPv1 there is no indication of the access privileges of
-- &&    of the various views (which is read-only, which is read-write),
-- &&    although this isn't really a problem with SNMPv1!
-- && In some ways for SNMPv1 the table need more information, for SNMPv2
-- && that information is held in the SNMPv2 MIB party and context tables.
chasEntityViewTable  OBJECT-TYPE
    SYNTAX      SEQUENCE OF ChasEntityViewEntry
    ACCESS      not-accessible
    STATUS      mandatory
    DESCRIPTION
        "A table of all MIB views orgainized by entity.
         Each entity may have a number of MIB views
         associated with it."
    ::= { chasEntity 2 }

chasEntityViewEntry  OBJECT-TYPE
    SYNTAX      ChasEntityViewEntry
    ACCESS      not-accessible
    STATUS      mandatory
    DESCRIPTION
            "Defines a specific MIB view."
    INDEX { chasEntityViewEntityId, chasEntityViewIndex }

ChasEntityViewEntry  ::= SEQUENCE {
    chasEntityViewEntityId        INTEGER,
    chasEntityViewIndex           INTEGER,
    chasEntityTDomain             OBJECT IDENTIFIER,
    chasEntityTAddress            OCTET STRING,
    chasEntityCommunity           DisplayString,
    chasEntityContext             Context
}

chasEntityViewEntityId  OBJECT-TYPE
    SYNTAX  INTEGER (1..65535)
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "The unique entity for which this MIB view is
         defined.  This is an instance of chasEntityIndex
         within the chasEntityTable."
    ::= { chasEntityViewEntry 1 }

chasEntityViewIndex  OBJECT-TYPE
    SYNTAX  INTEGER (1..127)
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "Distinguishes this view of the entity from other
         possible views."
    ::= { chasEntityViewEntry 2 }

chasEntityTDomain OBJECT-TYPE
    SYNTAX  OBJECT-IDENTIFIER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "This object identifies the protocol by which the view of the
         entity identified by this row in the table may be accessed. Note
         that different views of the same entity may be visible via different
         transport protocols. That is some bilingual stacks could include
         views visible via SNMPv1 over IP and also by SNMPv1 over IPX."
    ::= { chasEntityViewEntry 3}

chasEntityTAddress OBJECT-TYPE
    SYNTAX  TAddress
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "The transport service address by which the entity identified by
         this row of in the table may be accessed. The format of the
         address is determined by the value of chasEntityTAddress."
    ::= { chasEntityViewEntry 4}

chasEntityCommunity  OBJECT-TYPE
    SYNTAX  OCTET STRING (SIZE (0..255))
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "The SNMPv1 Community which is used to access, via the
         transport domain identified by chasEntityTDomain and
         chasEntityTAddress, the view of the entity identified
         by this row in the this table.

         If the view of the entity identified by this table row
         is not accessed by SNMPv1 then the value of this object for this
         row will be the zero length string.

         Note that it is possible to have seperate views of the same device
         accessed via different protocols. This is possible particular until
         SNMPv2 becomes established and is potentially true of bilingual
         agents."
    ::= { chasEntityEntry 5 }

chasEntityContext    OBJECT-TYPE
    SYNTAX  Context
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "The SNMPv1 Context which is used to access, via the
         transport identified by chasEntityTDomain and
         chasEntityTAddress, the view of the entity identified
         by this row in the this table.

         If the view of the entity identified by this table row
         is not accessed by SNMPv2 then the value of this object
         for this row will be the NULL OID {0 0}.

         Note that it is possible to have seperate views of the same entity
         accessed via different protocols. This is possible particular until
         SNMPv2 becomes established and is potentially true of bilingual
         agents."
    ::= { chasEntityEntry 6 }

-- The chasResource group.
-- This defines a mapping of physical relationship (modules/resources)

-- and a logical mapping of resource to entities.

-- Implementation of the resource group is mandatory.

-- Each physical module contains a number of logical
-- resource. Each resource is a building
-- block for constructing functional entities. This
-- table contains an entry for each resource in the
-- chassis, the type of entity this resource can
-- belong to and the current entity to which this
-- resource is assigned."

-- NOTE. In this model a resource resides on a module and is
-- entirely located on that module. This means there is a one to
-- one correspondance of resource to module.

-- NOTE. In this model a resource belongs to exactly ONE resource
-- at any particluar time. This means that there is always a
-- one to one correspondance of resource to entity.

chasPhyResourceTable  OBJET-TYPE
    SYNTAX  SEQUENCE of ChasPhyResourceEntry
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "This table contains one entry per resource in a particular
         chassis configuration. The table identifies each resource
         by its physical location within the chassis. In this way the
         table provides a direct mapping from resource to module.

         The table contains columns which identify the entity to which
         each resource is currently assigned, if any and so an indirect
         mapping is provided from resource to entity.

         If a particular chassis allows the software, or management
         configuration of resources to entities then this table controls
         that assignment by allowing the chasPhyResAssignment to be
         writable."
    ::= { chasResource 1 }

chasPhyResourceEntry  OBJECT-TYPE
    SYNTAX  ChasPhyResourceEntry
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
            "Defines a particular physical configuration relationship."
    INDEX { chasPhyResLocationType,
            chasPhyResLocation,
            chasPhyResIndex }
    ::= { chasResourceTable 1 }

ChasPhyResourceEntry ::= SEQUENCE {
    chasPhyResLocationType        INTEGER,
    chasPhyResLocation            INTEGER,
    chasPhyResIndex               INTEGER,
    chasPhyResType                OBJECT IDENTIFIER,
    chasPhyResEntityType          OBJECT IDENTIFIER,
    chasPhyResAssignment          INTEGER,
    chasPhyResEntitySubIndex      INTEGER
    }

chasPhyResLocationType  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A resource exists on a particular module.  A
         module is identified by it's physical location.
         Physical location is defined location type and an
         instance of that physical location type.  This
         object defines the location type.  This object can
         be used in conjunction with chasPhyResLocation to
         index the module table."
    ::= { chasPhyResourceEntry 1 }

chasPhyResLocation  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A resource exists on a particular module.  A
         module is identified by it's physical location.
         Physical location is defined location type and an
         instance of that physical location type.  This
         object defines a particular instance of the
         physical location."
    ::= { chasPhyResourceEntry 2 }

chasPhyResIndex  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
            "A unique index for the chassis resource on this
            particular physical module."
    ::= { chasPhyResourceEntry 3 }

chasPhyResType OBJECT-TYPE
    SYNTAX OBJECT IDENTIFIER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The type of resource. A number of values for this
         object are defined at the start of this MIB module
         under the chasResTypes branch. Other values may be
         defined for specific enterprises."
    ::= { chasPhyResourceEntry 4 }

chasPhyResEntityType OBJECT-TYPE
    SYNTAX OBJECT IDENTIFIER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The value of this object identifies the type of entity to which this
         resource may be assigned. Suitable values are defined at the start of
         this MIB module under the chasEntityTypes branch.

         This object is provided so that an intelligent management application
         can provide a list of suitable existing entites to which this
         resource may be assigned. For assigment to be successful, the
         value of this object must match the value of chasEntityObjectId
         in the chasEntityTable for the entity to which the resource is
         to be assigned."
    ::= { chasPhyResourceEntry 5 }

chasPhyResAssignment OBJECT-TYPE
    SYNTAX  INTEGER
    access  read-write
    STATUS  mandatory
    DESCRIPTION
        "Each resource may be 'assigned' to an existing entity. The
         value of this object identifies the entity to which this object
         is currently assigned. If the resource identified by a
         particular row in this table is not currently assigned to
         an entity then the value of this object for that row will be

      zero.

         Note that some implementations of this MIB may make this
         object writable. The effect of doing this is to allow
         standard management operations to dynamically reconfigure
         the resource of the chassis. Note that even if a
         specific implementation allows this object to be written,
         such operations may still fail if an illegal assignment
         is attempted. Illegal assignment includes assignment to a
         non-existent row, assignment to an inappropriate entity, eg
         an 802.3 repeater port to a token ring!

         Successfully changing the value of this object may have the
         side effect of changing the value of chasPhyResEntitySubIndex.
         The change will also be reflected in the chasLogResourceTable."
    ::= { chasPhyResourceEntry 6 }

chasPhyResEntitySubIndex  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A value that allows correlation with the cahsLogResourceTable.
         For each resource in this table which is assigned to an entity,
         there will be a corresponding row in the chasLogResourceTable.
         The row in the logical table is identified by indexing that table
         on the values of chasPhyResAssignment and chasPhyResEntitySubIndex.

         If a resource is not currently assigned to an entity, the value of
         this object for that resource will be zero and there will be no
         corresponding entry in chasLogResourceTable."
    ::= { chasPhyResourceEntry 7 }

-- Logical configuration/resource table

chasLogResourceTable  OBJECT-TYPE
        SYNTAX SEQUENCE OF ChasLogResourceEntry
        ACCESS not-accessible
        STATUS mandatory
        DESCRIPTION
            "This table contains a row for each resource in the system that
             is currently assigned to a particular entity. This table allows
             a direct mapping from entity to resource via the indices.

             The resource itself is identified by its location within the
             chassis.

             Note that no changes can be made to this table directly. The
             table will change when the physical configuration of the
             chassis changes or when the resource assignment is changed
             by access to chasPhyResourceTable."
        ::= { chasResource 2 }

chasLogResourceEntry OBJECT-TYPE
        SYNTAX ChasLogResourceEntry
        ACCESS not-accessible
        STATUS mandatory
        DESCRIPTION
            "Defines a single logical relationship."
        INDEX { chasLogResourceEntity,
                chasLogResourceEntitySubIndex }
        ::= { chasLogResourceTable 1 }

ChasLogResourceEntry  SEQUENCE {
        chasLogResEntity
                INTEGER,
        chasLogResEntitySubIndex
                INTEGER,
        chasLogResLocationType
                INTEGER,
        chasLogResLocation
                INTEGER,
        chasLogResID
                INTEGER
        }

chasLogResEntity  OBJECT-TYPE
        SYNTAX INTEGER
        ACCESS read-only
        STATUS mandatory
        DESCRIPTION
            "The entity ID for which this logical configuration
             relationship exists."
        ::= { chasLogResourceEntry 1 }

chasLogResEntitySubIndex  OBJECT-TYPE
        SYNTAX INTEGER
        ACCESS read-only
        STATUS mandatory
        DESCRIPTION
            "This object is used simply to provide for multiple
             resources assigned to a single entity."
        ::= { chasLogResourceEntry 2 }

chasLogResLocationType  OBJECT-TYPE
        SYNTAX INTEGER
        ACCESS read-only
        STATUS mandatory
        DESCRIPTION
            "This object, in conjuntion with the value of
             chaLogResLocation identifies the module on
             which the resource refered to by this table row
             resides."
        ::= { chasLogResourceEntry 3 }

chasLogResLocation  OBJECT-TYPE
        SYNTAX INTEGER
        ACCESS read-only
        STATUS mandatory
        DESCRIPTION
            "This object, in conjuntion with the value of
             chaLogResLocationType identifies the module on
             which the resource refered to by this table row
             resides."
        ::= { chasLogResourceEntry 4 }

chasLogResID  OBJECT-TYPE
        SYNTAX INTEGER
        ACCESS read-only
        STATUS mandatory
        DESCRIPTION
            "A module potentially contains many resources. The value of this
             object identifies the specific resource instance on this
             module to which this table row defines an entity mapping."
        ::= { chasLogResourceEntry 5 }
 
-- The chasInterconnect group.
-- This group is OPTIONAL and is provided for those chassis that are
-- prepared to or are capable of reporting internal resource interconnection
-- information. The basic idea of this table is that it contains
-- 'link descriptions'. Each such description documents a known connection
-- between two resources in the chassis. There is no requirement to
-- itemise all traffic links between resources in the chassis. For example
-- if this were required then a link from every repeater port to every other
-- repeater port in a repeater would be required.
--
-- Useful interconnections that could be documented in this table are
-- mappings from bridge and router ports to repeater ports. eg a
-- bridge/router card contains a seperate bridge and router, but both share
-- the same logical repeater ports to the backplane. eg:

--           +-----------+   +----------------+   +-----------+
--       +<--]Bdge Port 1]<--] Bridge Relay   ]-->]Bdge Port 2]-->+
--       ]   +-----------+   +----------------+   +-----------+   ]
--       ]                                                        ]
--       V   +-----------+   +----------------+   +-----------+   V
--       +<--]Rter Port 1]<--]  Relay Relay   ]-->]Rter Port 2]-->+
--       ]   +-----------+   +----------------+   +-----------+   ]
--       ]                                                        ]
-- +-------------+                                         +-------------+
-- ]Repeater Pt 1]                                         ]Repeater Pt 2]
-- +-------------+                                         +-------------+

-- Now in this case it is useful to know which bridge ports map to which
-- repeater ports, given that both are in different entities.

chasLinkTable  OBJECT-TYPE
    SYNTAX SEQUENCE OF ChasLinkEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "This table contains entity/resource interconnection information. Note
         that this information in this table is read-only."
    ::= { chasInterconnect 1 }

chasLinkEntry OBJECT-TYPE
    SYNTAX ChasLinkEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "Each entry in this table describes a link between two resources."
    INDEX { chasLinkIndex }
        ::= { chasLinkTable 1 }

ChasLogResourceEntry  SEQUENCE {
        chasLinkIndex                INTEGER,

        chasLinkFromLocType          INTEGER,
        chasLinkFromLoc              INTEGER,
        chasLinkFromResourceId       INTEGER,
        chasLinkFromIf               INTEGER,

        chasLinkToLocType            INTEGER,
        chasLinkToLoc                INTEGER,
        chasLinkToResourceId         INTEGER,
        chasLinkToIf                 INTEGER
}

chasLinkIndex  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "This object is used to identify one of the link
         specifications in this table."
    ::= { chasLinkEntry 1 }

chasLinkFromLocType  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkFromLoc and
         chasLinkFromResourceId identfiy the start of the link."
    ::= { chasLinkEntry 2 }

chasLinkFromLoc  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkFromLocType and
         chasLinkFromResourceId identfiy the start of the link."
    ::= { chasLinkEntry 3 }

chasLinkFromResourceId  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkFromLocType and
         chasLinkFromLoc identfiy the start of the link."
    ::= { chasLinkEntry 4 }

chasLinkFromIfNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "This object can be used to correlate the resource to an entry in
         an ifTable visible through the entity to which this resource belongs.
         Without this object there is no correlation between a resource and
      an entities ifTable. Note that if this value is zero then either
         the information is not available OR is not applicable."
    ::= { chasLinkEntry 5 }

chasLinkToLocType  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkToLoc and
         chasLinkToResourceId identfiy the end of the link."
    ::= { chasLinkEntry 6 }

chasLinkToLoc  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkToLocType and
         chasLinkToResourceId identfiy the end of the link."
    ::= { chasLinkEntry 7 }

chasLinkToResourceId  OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "A link is defined to be between one resource and another. This
         object identifies is a partial definition of one end of the link.
         This object in conjuntion with chasLinkToLocType and
         chasLinkToResourceId identfiy the end of the link."
    ::= { chasLinkEntry 8 }

chasLinkFromIfNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "This object can be used to correlate the resource to an entry in
         an ifTable visible through the entity to which this resource belongs.
         Without this object there is no correlation between a resource and
         an entities ifTable. Note that if this value is zero then either
         the information is not available OR is not applicable."
    ::= { chasLinkEntry 9 }

 
-- the Power Supply Output table. Note that this table contains
-- additional information for resources that represent power
-- supplies. As such this table has the same index as the resource
-- table. When the MIB is represented in an SNMPv2 manner the
-- index columns can be removed from this table and the INDEX
-- clause can refer to the resource table. Alternatively since
-- this table requires exactly the same indices as the resource
-- table it is a good candidate for the AUGMENTS clause!
--
-- && Note that identifying PS resouces differently here to the
-- && resource table is confusing.
chasPowerSupplyOutputTable OBJECT-TYPE
    SYNTAX SEQUENCE OF ChasPowerSupplyOutputEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "Additional information for resource that represent source
    of power within the chassis."
    ::= { chasPowerSupply 2 }

chasPowerSupplyOutputEntry OBJECT-TYPE
    SYNTAX ChasPowerSupplyEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
  "Values for a power supply output."
    INDEX { chasPSLocationType, chasPSLocationIndex,chasPSResource}
    ::= { chasPowerSupplyOutputTable 1 }

ChasPowerSupplyOutputEntry ::=
    SEQUENCE {
        chasPSLocationType            INTEGER,
        chasPSLocationIndex           INTEGER,
        chasPSResource                INTEGER,
        chasPSOutputStatus            INTEGER,
        chasPSOutputNominalVoltage    INTEGER,
        chasPSOutputOfferedVoltage    INTEGER,
        chasPSOutputOfferedWattage    INTEGER,
        chasPSOutputWarnings          Counter,
        chasPSOutputFailures          Counter
    }

chasPSLocationType  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A Power Supply resource exists on a particular module.
         This variable identifies the type part of the module on
         which this resource resides. It can be used with
         chasPSULocationIndex to index the module table for information
         about the module.

         The value of this object could be chasPowerSupplyBay, however
         some chassis implementations will not distinguish between
         slots that accept modular function card and those that accept
         power supplies. A slot can accept for example a power supply
         or a repeater line card."
    ::= { chasPowerSupplyOutputEntry 1 }

chasPSLocationIndex  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A power supply resource exists on a particular module. A module
         is identified by its location type and location instance.
         This variable identifies the instance part of the module
         identification on which this resource resides. It can be
         used with chasPSLocationType to index the module table
         for information about the module."
    ::= { chasPowerSupplyOutputEntry 2 }

chasPSResource  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
         "A unique index for the power supply resource on this
          particular physical module."
    ::= { chasPowerSupplyOutputEntry 3 }

chasPSOutputStatus OBJECT-TYPE
    SYNTAX INTEGER {
        unknown         (1),
        bad             (2),
        warning         (3),
        good            (4)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Actual status of the power supply:

            - unknown(1)     status not known
            - bad(2)         unable to supply power due to failure
            - warning(3)     supplying power but marginally
            - good(4)        supplying power

        It is an implementation specific matter whether
        the agent keeps entries with status unknown(1) in
        the table.  If unknown(1), offered values and
        counters are meaningless."
                ::= { chasPowerSupplyOutputEntry 4 }

chasPSOutputNominalVoltage OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
           "In hundredths of a volt, the voltage
            the output is supposed to supply, such
            as -5, +5, +12, -15, etc."
   ::= { chasPowerSupplyOutputEntry 5 }

chasPSOutputOfferedVoltage OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
          "In hundredths of a volt, the voltage
           actually offered by the output.  If
           chasPowerSupplyOutputStatus is good(4),
           the value 0 means offered voltage is
           not available."
  ::= { chasPowerSupplyOutputEntry 6 }

chasPSOutputOfferedWattage OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
          "In hundredths of a watt, the wattage
          actually offered by the output.  If
          chasPowerSupplyOutputStatus is good(4),
          the value 0 means offered wattage is not
          available."
 ::= { chasPowerSupplyOutputEntry 7 }

chasPSOutputWarnings OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
         "The number of times
         chasPowerSupplyOutputStatus has gone to
         warning(3)."
    ::= { chasPowerSupplyOutputEntry 8 }

chasPSOutputFailures OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The number of times chasPowerSupplyOutputStatus
         has gone to bad(2)."
    ::= { chasPowerSupplyOutputEntry 9 }

-- the chasEnviron (Environment) group
-- Implementation of this group is optional.

-- && In the same way that each power supply is
-- && a resource, so is each environmental monitor. This
-- && table can also be described as an AUGMENTS or a shared
-- && index with the resource table. In the long run it is
-- && more economical on MIB objects to share the indices
-- && with the resource table. In preparation for this I've
-- && changed this table to use the location type and index
-- && to identify rows in this table.
-- &&
-- && Because a sensor is a resource, its can be identified
-- && by the OID in the resource table so chasEnvironSensor
-- && is no longer required.
chasEnvironTable OBJECT-TYPE
    SYNTAX SEQUENCE OF ChasEnvironEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
        "A list of environmental entries, one for
        each environmental sensor in the chassis. This table
        augments the resources in the resource table for those
        entries which represent sensors."
    ::= { chasEnviron 1 }

chasEnvironEntry OBJECT-TYPE
    SYNTAX ChasEnvironEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION "Values for a environmental sensor."
    INDEX { chasEnvironLocationType,
            chasEnvironLocationIndex,
            chasEnvironResource }
    ::= { chasEnvironTable 1 }

ChasEnvironEntry ::= SEQUENCE {
    chasEnvironLocationType                     INTEGER,
    chasEnvironLocationIndex                    INTEGER,
    chasEnvironResource                         INTEGER,
    chasEnvironStatus                           INTEGER,
    chasEnvironWarnings                         Counter,
    chasEnvironFailures                         Counter,
}

chasEnvironLocationType  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
 STATUS  mandatory
    DESCRIPTION
        "A sensor resource exists on a particular module.
         This variable identifies the type part of the module on
         which this sensor resides."
    ::= { chasEnvironEntry 1 }

chasEnvironLocationIndex  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A sensor exists on a particular module. A module
         is identified by its location type and location instance.
         This variable identifies the instance part of the module
         identification on which this sensor resides."
    ::= { chasEnvironEntry 2 }

chasEnvironResource  OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
        "A unique index for the resource on this particular physical module."
    ::= { chasEnvironEntry 3 }

chasEnvironStatus OBJECT-TYPE
    SYNTAX INTEGER {
         unknown    (1),
         bad        (2),
         warning    (3),
         good       (4)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
          "Actual status indicated by the sensor.  It is
           an implementation specific matter whether the
           agent keeps entries with status unknown(1) in
           the table.  If unknown(1), counters are
           meaningless."
    ::= { chasEnvironEntry 4 }

chasEnvironWarnings OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
         "The number of times chasEnvironStatus has gone
         to warning(3)."
    ::= { chasEnvironEntry 5 }

chasEnvironFailures OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The number of times chasEnvironStatus has gone
        to bad(2)."
    ::= { chasEnvironEntry 6 }
END