snmpFddiPORTConnectState OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
connecting(2),
standby(3),
active(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An indication of the connect state of this PORT.
Basically, this gives a higher level view of the
state of the connection by grouping PCM states and
the PC-Withhold flag state. The supported values
and their corresponding PCM states and PC-Withhold
condition, when relevant, are:
disabled: (PC0:Off, PC9:Maint)
connecting: (PC1(Break) || PC3 (Connect) || PC4
(Next) || PC5 (Signal) || PC6
(Join) || PC7 (Verify)) &&
(PC_Withhold = None)
standby: (NOT PC_Withhold == None)
active: (PC2:Trace || PC8:Active) "
REFERENCE
"ANSI { fddiPORT 61 }"
::= { snmpFddiPORTEntry 20 }
snmpFddiPORTPCMState OBJECT-TYPE
SYNTAX INTEGER {
pc0(1), -- Off
pc1(2), -- Break
pc2(3), -- Trace
pc3(4), -- Connect
pc4(5), -- Next
pc5(6), -- Signal
pc6(7), -- Join
pc7(8), -- Verify
pc8(9), -- Active
pc9(10) -- Maint
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"(refer to SMT 9.6.2)."
REFERENCE
"ANSI { fddiPORT 62 }"
::= { snmpFddiPORTEntry 21 }
snmpFddiPORTPCWithhold OBJECT-TYPE
SYNTAX INTEGER { none(1), m-m(2), other(3) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"PC_Withhold, (refer to ANSI SMT 9.4.1)."
REFERENCE
"ANSI { fddiPORT 63 }"
::= { snmpFddiPORTEntry 22 }
snmpFddiPORTLerCondition OBJECT-TYPE
SYNTAX INTEGER { true(1), false(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable is set to true whenever LerEstimate
is less than or equal to LerAlarm."
REFERENCE
"ANSI { fddiPORT 64 }"
::= { snmpFddiPORTEntry 23 }
snmpFddiPORTChipSet OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the hardware chip(s) which
is (are) principally responsible for the
implementation of the PORT (PHY) function. A few
OBJECT IDENTIFIERS are identified elsewhere in
this memo. For those The assignment of additional
OBJECT IDENTIFIERs to various types of hardware
chip sets is managed by the IANA. For example,
vendors whose chip sets are not defined in this
memo may request a number from the Internet
Assigned Numbers Authority (IANA) which indicates
the assignment of a enterprise specific subtree
which, among other things, may be used to allocate
OBJECT IDENTIFIER assignments for that
enterprise's chip sets. Similarly, in the absence
of an appropriately assigned OBJECT IDENTIFIER in
this memo or in an enterprise specific subtree of
a chip vendor, a board or system vendor can
request a number for a subtree from the IANA and
make an appropriate assignment. It is desired
that, whenever possible, the same OBJECT
IDENTIFIER be used for all chips of a given type.
Consequently, the assignment made in this memo for
a chip, if any, should be used in preference to
any other assignment and the assignment made by
the chip manufacturer, if any, should be used in
preference to assignments made by users of those
chips. If the hardware chip set is unknown, the
object identifier
unknownChipSet OBJECT IDENTIFIER ::= { 0 0 }
is returned. Note that unknownChipSet is a
syntactically valid object identifier, and any
conformant implementation of ASN.1 and the BER
must be able to generate and recognize this
value."
::= { snmpFddiPORTEntry 24 }
snmpFddiPORTAction OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- none of the following
maintPORT(2),
enablePORT(3),
disablePORT(4),
startPORT(5),
stopPORT(6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object, when read, always returns a value of
other(1). The behavior of setting this variable
to each of the acceptable values is as follows:
Other: Results in a badValue error.
maintPORT: Signal PC_Maint
enablePORT: Signal PC_Enable
disablePORT: Signal PC_Disable
startPORT: Signal PC_Start
stopPORT: Signal PC_Stop
Signals cause an SM_CM_CONTROL.request service to
be generated with a control_action of `Signal' and
the `variable' parameter set with the appropriate
value (i.e., PC_Maint, PC_Enable, PC_Disable,
PC_Start, PC_Stop). Ref. ANSI SMT Section 9.3.2.
Attempts to set this object to all other values
results in a badValue error."
REFERENCE
"ANSI { fddiPORT 70 }"
::= { snmpFddiPORTEntry 25 }
-- the ATTACHMENT group
-- Implementation of the ATTACHMENT group is mandatory for
-- all systems which implement manageable FDDI subsystems.
snmpFddiATTACHMENTNumber OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of attachments (across all SMTs)
on this network management application entity.
The value for this variable must remain constant
at least from one re-initialization of the
entity's network management system to the next
re-initialization."
::= { snmpFddiATTACHMENT 1 }
-- the ATTACHMENT table
snmpFddiATTACHMENTTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpFddiATTACHMENTEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of ATTACHMENT entries. The number of
entries is given by the value of
snmpFddiATTACHMENTNumber."
::= { snmpFddiATTACHMENT 2 }
snmpFddiATTACHMENTEntry OBJECT-TYPE
SYNTAX SnmpFddiATTACHMENTEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An ATTACHMENT entry containing information common
to a given set of ATTACHMENTs.
The ATTACHMENT Resource represents a PORT or a
pair of PORTs plus the optional associated optical
bypass that are managed as a functional unit.
Because of its relationship to the PORT Objects,
there is a natural association of ATTACHMENT
Resource Indices to the PORT Indices. The
resource index for the ATTACHMENT is equal to the
associated PORT index for 'single-attachment' and
'concentrator' type snmpFddiATTACHMENTClasses.
For 'dual-attachment' Classes, the ATTACHMENT
Index is the PORT Index of the A PORT of the A/B
PORT Pair that represents the ATTACHMENT."
INDEX { snmpFddiATTACHMENTSMTIndex,
snmpFddiATTACHMENTIndex }
::= { snmpFddiATTACHMENTTable 1 }
SnmpFddiATTACHMENTEntry ::=
SEQUENCE {
snmpFddiATTACHMENTSMTIndex
INTEGER,
snmpFddiATTACHMENTIndex
INTEGER,
snmpFddiATTACHMENTClass
INTEGER,
snmpFddiATTACHMENTOpticalBypassPresent
INTEGER,
snmpFddiATTACHMENTIMaxExpiration
FddiTime,
snmpFddiATTACHMENTInsertedStatus
INTEGER,
snmpFddiATTACHMENTInsertPolicy
INTEGER
}
snmpFddiATTACHMENTSMTIndex OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of the SMT index associated with this
ATTACHMENT."
::= { snmpFddiATTACHMENTEntry 1 }
snmpFddiATTACHMENTIndex OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A unique value for each ATTACHMENT on a given
SMT. Its value ranges between 1 and the sum of
the values of snmpFddiSMTNonMasterCt {
snmpFddiSMTEntry 6 } and snmpFddiSMTMasterCt {
snmpFddiSMTEntry 7 } on the given SMT. The value
for each ATTACHMENT must remain constant at least
from one re-initialization of the entity's network
management system to the next re-initialization."
::= { snmpFddiATTACHMENTEntry 2 }
snmpFddiATTACHMENTClass OBJECT-TYPE
SYNTAX INTEGER {
single-attachment(1),
dual-attachment(2),
concentrator(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Attachment class. This represents a PORT or
a pair of PORTs plus the associated optional
optical bypass that are managed as a functional
unit. The PORT associations are the following:
single-attachment - S PORTs
dual-attachment - A/B PORT Pairs
concentrator - M PORTs "
REFERENCE
"ANSI { fddiATTACHMENT 11 }"
::= { snmpFddiATTACHMENTEntry 3 }
snmpFddiATTACHMENTOpticalBypassPresent OBJECT-TYPE
SYNTAX INTEGER { true(1), false(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this value is false for 'single-
attachment' and { snmpFddiATTACHMENT 11 }.
Correct operation of CMT for single-attachment and
concentrator attachments requires that a bypass
function must not loopback the network side of the
MIC, but only the node side."
REFERENCE
"ANSI { fddiATTACHMENT 12 }"
::= { snmpFddiATTACHMENTEntry 4 }
snmpFddiATTACHMENTIMaxExpiration OBJECT-TYPE
SYNTAX FddiTime
ACCESS read-only
STATUS mandatory
DESCRIPTION
"I_Max (refer to ANSI SMT 9.4.4.2.1). It is
recognized that some currently deployed systems do
not implement an optical bypass. Systems which do
not implement optical bypass should return a value
of 0."
REFERENCE
"ANSI { fddiATTACHMENT 13 }"
::= { snmpFddiATTACHMENTEntry 5 }
snmpFddiATTACHMENTInsertedStatus OBJECT-TYPE
SYNTAX INTEGER { true(1), false(2), unimplemented(3) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the attachment is currently
inserted in the node."
REFERENCE
"ANSI { fddiATTACHMENT 14 }"
::= { snmpFddiATTACHMENTEntry 6 }
snmpFddiATTACHMENTInsertPolicy OBJECT-TYPE
SYNTAX INTEGER { true(1), false(2), unimplemented(3) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicates the Insert Policy for this Attachment.
Insert: True (1), Don't Insert: False (2),
Unimplemented (3)"
REFERENCE
"ANSI { fddiATTACHMENT 15 }"
::= { snmpFddiATTACHMENTEntry 7 }
-- the Chip Set group
-- The following object identifiers are allocated for use
-- with the snmpFddiMACChipSet and snmpFddiPORTChipSet
-- variables.
snmpFddiPHYChipSets -- Chips primarily responsible
-- for implementing the PHY
-- function.
OBJECT IDENTIFIER ::= { snmpFddiChipSets 1 }
-- None defined at present
-- Chipsets may someday be
-- defined here
snmpFddiMACChipSets -- Chips primarily responsible
-- for implementing the
-- MAC function.
OBJECT IDENTIFIER ::= { snmpFddiChipSets 2 }
-- None defined at present
-- Chipsets may someday be
-- defined here
snmpFddiPHYMACChipSets -- Chips which implement both
-- the PHY and MAC functions
OBJECT IDENTIFIER ::= { snmpFddiChipSets 3 }
-- None defined at present
-- Chipsets may someday be
-- defined here
END
6. Acknowledgements
This document was produced by the IETF FDDI MIB working group:
Steve Adams, Digital Equipment Corporation
Hossein Alaee, 3Com Corporation
Haggar Alsaleh, Bell Northern Research
William Anderson, Mitre Corporation
Alan Apt, Addison-Wesley
Mary Artibee, Silicon Graphics
Karen Auerbach, Epilogue Technologies
Doug Bagnall, Apollo/Hewlett Packard
Chet Birger, Coral Network Corporation
Pablo Brenner, Sparta
Howard Brown, Cabletron
Jack Brown, US Army Computer Engineering Center
Eric Brunner
Jeff Case, The University of Tennessee
Tammy Chan, Fibercom
Asheem Chandna, AT&T
Cho Y. Chang, Apollo/Hewlett Packard
Chris Chiotasso, Fibronics
Paul Ciarfella, Digital Equipment Corporation
John Cook, Chipcom
Don Coolidge, Silicon Graphics
Burt Cyr, Unisys
James R. Davin, Massachusetts Institute of Technology
Nabil Damouny
Nadya El-Afandi, Network Systems Corporation
Hunaid Engineer, Cray Research
Jeff Fitzgerald, Fibercom
Richard Fox, Synoptics
Stan Froyd, ACC
Debbie Futcher, U.S. Naval Surface Warfare Center
Joseph Golio, Cray Research
Jeremy Greene, Coral
Brian D. Handspicker, Digital Equipment Corporation
Peter Hayden, Digital Equipment Corporation
Scott Hiles, U.S. Naval Surface Warfare Center
Greg Jones, Data General
Satish Joshi, SynOptics Communications
Jayant Kadambi, AT&T Bell Labs
Joanna Karwowska, Data General
Frank Kastenholz, Interlan
Jim Kinder, Fibercom
Christopher Kolb, PSI
Cheryl Krupczak, NCR
Peter Lin, Vitalink
Then Liu
John R. LoVerso, Concurrent Computer Corporation
Ron Mackey
Gary Malkin, Proteon
Bruce McClure, Synernetics
Keith McCloghrie, Hughes Lan Systems
Donna McMaster, SynOptics
John O'Hara, Massachusetts Institute of Technology
Dave Perkins, SynOptics Communications
James E. Reeves, SynOptics Communications
Jim Reinstedler, Ungermann-Bass
Radhi Renous, Fibronics
Anil Rijsinghani, Digital Equipment Corporation
Bob Rolla, Synernetics
Nelson Ronkin, Synernetics
Marshall T. Rose, Performance Systems International, Inc.
Milt Roselinsky, CMC
Jon Saperia, Digital Equipment Corporation
Greg Satz, cisco Systems
Steven Senum, Network Systems Corporation
Jim Sheridan, IBM Corporation
Jeffrey Schiller, MIT
Dror Shindelman, Sparta
Mark Sleeper, Sparta
Craig Smelser, Digital Equipment Corporation
Lou Steinberg, IBM Corporation
Mary Jane Strohl, Apollo/Hewlett Packard
Sally Tarquinio, Mitre Corporation
Kaj Tesink, Bellcore
Ian Thomas, Chipcom
Dean Throop, Data General
Bill Townsend, Xylogics
Ahmet H. Tuncay, SynOptics Communications
Mike Turico, Motorola
Chris VandenBerg, ACC
Sudhanshu Verma, Hewlett Packard
Joe Vermeulen, UNISYS
David Waiteman, BBN
Bert Williams, Synernetics
Mark Wood, AT&T Computer Systems
Y. C. Yang
Denis Yaro, Sun Microsystems
Jeff Young, Cray Research
The editor gratefully acknowledges the contributions of the editor of
the ANSI X3T9.5 SMT document, Mary Jane Strohl of Hewlett
Packard/Apollo, whose provision of that document in machine readable
form saved much typing and avoided many data entry errors.
The author gratefully acknowledges the labors of Dr. Marshall T. Rose
in assisting with converting this document to the new concise MIB
format.
8. References
[1] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[2] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[4] McCloghrie K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets", RFC1213,
Performance Systems International, March 1991.
[5] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[6] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC1212, Performance Systems International, Hughes LAN Systems,
March 1991.
[8] American National Standards Institute, "FDDI Station Management
(SMT)", Preliminary Draft Proposed American National Standard,
American National Standards Institute, X3T9/90-X3T9.5/84-49 REV
6.2, May 18, 1990.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Jeffrey D. Case
SNMP Research, Incorporated
3001 Kimberlin Heights Road
Knoxville, Tennessee 37920
Phone: (615) 573-1434
EMail: case@CS.UTK.EDU