Chassis MIB Proposal

{3COM/PDD/PeteW}@pdd.3mail.3com.com Tue, 04 January 1994 10:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01773; 4 Jan 94 5:09 EST
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa01763; 4 Jan 94 5:09 EST
Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id EAA12129; Tue, 4 Jan 1994 04:49:23 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 4 Jan 1994 04:49:22 EST
Errors-to: owner-chassismib@CS.UTK.EDU
Received: from relay2.UU.NET by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id EAA12122; Tue, 4 Jan 1994 04:49:20 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US
Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07803; Tue, 4 Jan 94 04:49:19 -0500
Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA14334; Tue, 4 Jan 94 01:49:01 PST
Received: by gw.3Com.COM id AA18519 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Tue, 4 Jan 1994 01:49:16 -0800
Date: Tue, 04 Jan 1994 09:44:00 -0800
Subject: Chassis MIB Proposal
To: chassismib@cs.utk.edu
Message-Id: <940104.015030@3Mail.3Com.COM>
Msg-Date: 1994-01-04
Msg-Time: 09:41

FROM: Wilson, Peter

TO:  {chassismib@cs.utk.edu}:ugate:3com                       DATE:  01-04-94
                                                              TIME:  09:39
CC:
SUBJECT:  Chassis MIB Proposal
PRIORITY:
ATTACHMENTS:

------------------------------------------------------------------------------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 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.