draft-ietf-ips-fcmgmt-mib-03.txt   draft-ietf-ips-fcmgmt-mib-04.txt 
Internet Draft Keith McCloghrie Internet Draft Keith McCloghrie
Cisco Systems, Inc Cisco Systems, Inc
10 October 2002 24 February 2003
Fibre Channel Management MIB Fibre Channel Management MIB
draft-ietf-ips-fcmgmt-mib-03.txt draft-ietf-ips-fcmgmt-mib-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is subject to all provisions of
provisions of Section 10 of RFC2026 [RFC2026]. Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress". or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited.
author.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) for This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In use with network management protocols in the Internet community. In
particular, it describes managed objects for informantion related to particular, it describes managed objects for information related to
Fibre Channel. Fibre Channel.
Table of Contents Table of Contents
1 The SNMP Network Management Framework ........................... 3 1 Introduction .................................................... 3
2 Change Log ...................................................... 4 2 The Internet-Standard Management Framework ...................... 4
3 Short Overview of Fibre Channel ................................. 5 3 Short Overview of Fibre Channel ................................. 4
4 MIB Overview .................................................... 6 4 MIB Overview .................................................... 5
4.1 The fcmInstanceBasicGroup group ............................... 6 5 Relationship to Other MIBs ...................................... 7
4.2 The fcmSwitchBasicGroup group ................................. 6 5.1 The Interfaces Group MIB ...................................... 7
4.3 The fcmPortBasicGroup group ................................... 6 5.2 Entity MIB .................................................... 10
4.4 The fcmPortStatsGroup group ................................... 6
4.5 The fcmPortClass23StatsGroup group ............................ 7
4.6 The fcmPortLcStatsGroup group ................................. 7
4.7 The fcmPortClassFStatsGroup group ............................. 7
4.8 The fcmPortErrorsGroup group .................................. 7
4.9 The fcmSwitchPortGroup group .................................. 7
4.10 The fcmSwitchLoginGroup group ................................ 7
4.11 The fcmLinkBasicGroup group .................................. 7
5 Relationship to Other MIBs ...................................... 8
5.1 The Interfaces Group MIB ...................................... 8
5.2 Entity MIB .................................................... 11
5.3 Host Resources MIB ............................................ 11 5.3 Host Resources MIB ............................................ 11
6 Definitions ..................................................... 12 6 Definitions ..................................................... 12
7 Intellectual Property ........................................... 63 7 Intellectual Property ........................................... 63
8 Acknowledgements ................................................ 63 8 Acknowledgements ................................................ 63
9 References ...................................................... 63 9 Normative References ............................................ 63
10 Security Considerations ........................................ 67 10 Informative References ......................................... 65
11 Comparison to draft-ietf-ipfc-fcmgmt-int-mib-07.txt ............ 69 11 Security Considerations ........................................ 66
12 Comparison to RFC 2837 ......................................... 76 12 Comparison to draft-ietf-ipfc-fcmgmt-int-mib-07.txt ............ 68
13 Author's Address ............................................... 77 12.1 Problems with draft-ietf-ipfc-fcmgmt-int-mib-07.txt .......... 68
14 Full Copyright Statement ....................................... 77 12.2 Detailed Changes ............................................. 69
12.3 Name Server objects .......................................... 73
1. The SNMP Network Management Framework 12.4 Additional objects ........................................... 74
13 Comparison to RFC 2837 ......................................... 75
The SNMP Management Framework presently consists of five major 14 Author's Address ............................................... 76
components: 15 Full Copyright Statement ....................................... 76
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].
The second version, called SMIv2, is described in RFC 2578
[RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [RFC1157]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed 1. Introduction
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A This memo defines a portion of the Management Information Base (MIB) for
MIB conforming to the SMIv1 can be produced through the appropriate use with network management protocols in the Internet community. In
translations. The resulting translated MIB must be semantically particular, it describes managed objects for information related to
equivalent, except where objects or events are omitted because no Fibre Channel.
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
2. Change Log 1.1. Change Log
This section to be deleted before publication as an RFC. This section to be deleted before publication as an RFC.
2.1. Initial version: draft-ietf-ips-fcmgmt-mib-00.txt 1.1.1. Initial version: draft-ietf-ips-fcmgmt-mib-00.txt
Initial version derived from draft-ietf-ipfc-fcmgmt-int-mib-07.txt and Initial version derived from draft-ietf-ipfc-fcmgmt-int-mib-07.txt and
RFC 2837, and published on 22 January 2002. RFC 2837, and published on 22 January 2002.
2.2. Changes made in draft-ietf-ips-fcmgmt-mib-01.txt 1.1.2. Changes made in draft-ietf-ips-fcmgmt-mib-01.txt
- support added for Class F traffic. - support added for Class F traffic.
- the description of Class 1 changed to "not widely-implemented" - the description of Class 1 changed to "not widely-implemented"
(instead of "obsolete"), and a reference to FC-MI added. (instead of "obsolete"), and a reference to FC-MI added.
- Counter32 objects added in order to support old SNMPv1-only systems - Counter32 objects added in order to support old SNMPv1-only systems
which cannot support standard Counter64 objects. which cannot support standard Counter64 objects.
2.3. Changes made in draft-ietf-ips-fcmgmt-mib-02.txt 1.1.3. Changes made in draft-ietf-ips-fcmgmt-mib-02.txt
- aligned the meanings of bits of the FcUnitFunctions TC with the latest - aligned the meanings of bits of the FcUnitFunctions TC with the latest
update to the meanings in the GS-4 specification. update to the meanings in the GS-4 specification.
- broadened the scope of the fcmEPortTable to apply to any type of port - broadened the scope of the fcmEPortTable to apply to any type of port
connected to an inter-swithc link, and changed its descriptor to connected to an inter-swithc link, and changed its descriptor to
fcmISPortTable. fcmISPortTable.
- changed the fcmLinkTable to be optional. - changed the fcmLinkTable to be optional.
- fixed some minor typos - fixed some minor typos
2.4. Changes made in draft-ietf-ips-fcmgmt-mib-03.txt 1.2. Changes made in draft-ietf-ips-fcmgmt-mib-03.txt
- 'storageDevice' was added as an enumeration of the FcUnitFunctions TC - 'storageDevice' was added as an enumeration of the FcUnitFunctions TC
for compatibility with the latest proposal in T11. for compatibility with the latest proposal in T11.
- fcmISPortClassFCredit was changed to have a MAX-ACCESS of read-write, - fcmISPortClassFCredit was changed to have a MAX-ACCESS of read-write,
but the minimum compliance was kept as read-only. but the minimum compliance was kept as read-only.
- several auxiliary objects were changed to exclude 0 as a possible - several auxiliary objects were changed to exclude 0 as a possible
value (as recommended in section 7.7 of RFC 2578). value (as recommended in section 7.7 of RFC 2578).
- the OIDs of the columnar objects in the fcmPortErrorsTable were - the OIDs of the columnar objects in the fcmPortErrorsTable were
renumbered so as to be consecutive. renumbered so as to be consecutive.
1.2.1. Changes made in draft-ietf-ips-fcmgmt-mib-04.txt
- updated boilerplate as required by the publication of RFCs 3410
through 3418.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Short Overview of Fibre Channel 3. Short Overview of Fibre Channel
The Fibre Channel (FC) is logically a bidirectional point-to-point The Fibre Channel (FC) is logically a bidirectional point-to-point
serial data channel, structured for high performance capability. The serial data channel, structured for high performance capability. The
Fibre Channel provides a general transport vehicle for higher level Fibre Channel provides a general transport vehicle for higher level
protocols such as Intelligent Peripheral Interface (IPI) and Small protocols such as Intelligent Peripheral Interface (IPI) and Small
Computer System Interface (SCSI) command sets, the High-Performance Computer System Interface (SCSI) command sets, the High-Performance
Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE
802.2, and others. 802.2, and others.
skipping to change at page 5, line 42 skipping to change at page 5, line 20
is interconnected to another switch port via an Inter Element Link is interconnected to another switch port via an Inter Element Link
(IEL), is called an E_Port. A B_Port connects a bridge device with an (IEL), is called an E_Port. A B_Port connects a bridge device with an
E_Port on a switch; a B_Port provides a subset of E_Port functionality. E_Port on a switch; a B_Port provides a subset of E_Port functionality.
Many Fibre Channel components, including the fabric, each node, and most Many Fibre Channel components, including the fabric, each node, and most
ports, have globally-unique names. These globally-unique names are ports, have globally-unique names. These globally-unique names are
typically formatted as World Wide Names (WWNs). More information on typically formatted as World Wide Names (WWNs). More information on
WWNs can be found in [WWN1] and [WWN2]. WWNs are expected to be WWNs can be found in [WWN1] and [WWN2]. WWNs are expected to be
persistent across agent and unit resets. persistent across agent and unit resets.
Fibre Channel frames contain 24-bit address identifers which identify Fibre Channel frames contain 24-bit address identifiers which identify
the frame's source and destination ports. Each FC port has an address the frame's source and destination ports. Each FC port has an address
identifier and a WWN. When a fabric is in use, the FC address identifier and a WWN. When a fabric is in use, the FC address
identifiers are dynamic and are assigned by a switch. identifiers are dynamic and are assigned by a switch.
4. MIB Overview 4. MIB Overview
This MIB contains the notion of a Fibre Channel management instance, This MIB contains the notion of a Fibre Channel management instance,
which is defined as a separable managed instance of Fibre Channel which is defined as a separable managed instance of Fibre Channel
functionality. Fibre Channel functionality may be grouped into Fibre functionality. Fibre Channel functionality may be grouped into Fibre
Channel management instances in whatever way is most convenient for the Channel management instances in whatever way is most convenient for the
skipping to change at page 12, line 11 skipping to change at page 12, line 11
MIB), then the value of fcmInstanceSoftwareIndex is zero. (Note that an MIB), then the value of fcmInstanceSoftwareIndex is zero. (Note that an
implementation is not required to support a non-zero value of implementation is not required to support a non-zero value of
fcmInstanceSoftwareIndex.) fcmInstanceSoftwareIndex.)
6. Definitions 6. Definitions
FC-MGMT-MIB DEFINITIONS ::= BEGIN FC-MGMT-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
Integer32, Unsigned32, Counter32, Counter64, experimental Integer32, Unsigned32, Counter32, Counter64, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
TruthValue, TEXTUAL-CONVENTION TruthValue, TEXTUAL-CONVENTION
FROM SNMPv2-TC FROM SNMPv2-TC
ifIndex FROM IF-MIB ifIndex FROM IF-MIB
SnmpAdminString FROM SNMP-FRAMEWORK-MIB; SnmpAdminString FROM SNMP-FRAMEWORK-MIB;
fcMgmtMIB MODULE-IDENTITY fcMgmtMIB MODULE-IDENTITY
LAST-UPDATED "200209250000Z" LAST-UPDATED "200209250000Z"
skipping to change at page 12, line 38 skipping to change at page 12, line 38
Postal: 170 West Tasman Drive Postal: 170 West Tasman Drive
San Jose, CA USA 95134 San Jose, CA USA 95134
" "
DESCRIPTION DESCRIPTION
"This module defines management information specific to "This module defines management information specific to
Fibre Channel-attached devices." Fibre Channel-attached devices."
REVISION "200209250000Z" REVISION "200209250000Z"
DESCRIPTION DESCRIPTION
"Initial version of the Fibre Channel Mgmt MIB module, "Initial version of the Fibre Channel Mgmt MIB module,
published as RFC xxxx." -- (to be assigned by RFC Editor) published as RFC xxxx." -- (to be assigned by RFC Editor)
::= { experimental 999999 } -- unassigned ::= { mib-2 999999 } -- to be assigned by IANA
fcmgmtObjects OBJECT IDENTIFIER ::= { fcMgmtMIB 1 } fcmgmtObjects OBJECT IDENTIFIER ::= { fcMgmtMIB 1 }
fcmgmtNotifications OBJECT IDENTIFIER ::= { fcMgmtMIB 2 } fcmgmtNotifications OBJECT IDENTIFIER ::= { fcMgmtMIB 2 }
fcmgmtNotifPrefix OBJECT IDENTIFIER ::= { fcmgmtNotifications 0 } fcmgmtNotifPrefix OBJECT IDENTIFIER ::= { fcmgmtNotifications 0 }
fcmgmtConformance OBJECT IDENTIFIER ::= { fcMgmtMIB 3 } fcmgmtConformance OBJECT IDENTIFIER ::= { fcMgmtMIB 3 }
--******************************** --********************************
-- Textual Conventions -- Textual Conventions
-- --
skipping to change at page 63, line 38 skipping to change at page 63, line 38
This memo is partly based on the information contained in the original This memo is partly based on the information contained in the original
submission of the Fibre Channel Management Integration MIB to the IETF's submission of the Fibre Channel Management Integration MIB to the IETF's
IPFC Working Group as draft-ietf-ipfc-fcmgmt-int-mib-0n.txt, and partly IPFC Working Group as draft-ietf-ipfc-fcmgmt-int-mib-0n.txt, and partly
based on RFC 2837. based on RFC 2837.
Feedback has been incorporated into this document based on the comments Feedback has been incorporated into this document based on the comments
of the following: Sudhir Pendse, SimpleSoft; Steve Senum, Cisco Systems; of the following: Sudhir Pendse, SimpleSoft; Steve Senum, Cisco Systems;
and Kha Sin Teow, Brocade. and Kha Sin Teow, Brocade.
9. References 9. Normative References
[RFC1155]
Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[RFC1157]
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[RFC1212]
Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
Performance Systems International, Hughes LAN Systems, March 1991.
[RFC1215]
M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, Performance Systems International, March 1991.
[RFC1901]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, Harvard University, October, 1996.
[RFC2570]
Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
Version 3 of the Internet-standard Network Management Framework",
RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates,
Inc., Ericsson, Cisco Systems, April 1999.
[RFC2571]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, Cabletron
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April
1999.
[RFC2572]
Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems,
Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999.
[RFC2573]
Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, April 1999.
[RFC2574]
Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2574, IBM T. J. Watson Research, April 1999.
[RFC2575]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc.,
Cisco Systems, Inc., April 1999.
[RFC2578] [RFC2578]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
and S. Waldbusser, "Structure of Management Information Version 2 and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU (SMIv2)", STD 58, RFC 2578, April 1999.
Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999.
[RFC2579] [RFC2579]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 2579, April 1999.
Virtual Holdings, International Network Services, April 1999.
[RFC2580] [RFC2580]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 2580, April 1999.
First Virtual Holdings, International Network Services, April 1999.
[RFC2737] [RFC2737]
McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737,
December 1999. December 1999.
[RFC2741]
Daniele, M., Wijnen, B., Ellison, M., and D. Francisco. "Agent
Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[RFC2790] [RFC2790]
Waldbusser, S., and P. Grillo, "Host Resources MIB", RFC 2790, Waldbusser, S., and P. Grillo, "Host Resources MIB", RFC 2790,
March 2000. March 2000.
[RFC2837]
Teow, K., "Definitions of Managed Objects for the Fabric Element in
Fibre Channel Standard", RFC 2837, May 2000.
[RFC2863] [RFC2863]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC
2863, Cisco Systems, Argon Networks, June, 2000. 2863, Cisco Systems, Argon Networks, June 2000.
[FC-AL] [FC-AL]
"Information Technology - Fibre Channel - Arbitrated Loop (FC-AL)", "Information Technology - Fibre Channel - Arbitrated Loop (FC-AL)",
ANSI X3.272, 1996. ANSI X3.272, 1996.
[FC-AL-2] [FC-AL-2]
"Fibre Channel - Arbitrated Loop (FC-AL-2)", ANSI NCITS 332-1999, "Fibre Channel - Arbitrated Loop (FC-AL-2)", ANSI NCITS 332-1999,
1999. 1999.
[FC-BB] [FC-BB]
skipping to change at page 67, line 13 skipping to change at page 65, line 16
"Information Technology - Fibre Channel Physical and Signaling "Information Technology - Fibre Channel Physical and Signaling
Interface (FC-PH)", ANSI X3.230, 1994. Interface (FC-PH)", ANSI X3.230, 1994.
[FC-SW] [FC-SW]
"Fibre Channel - Switch Fabric (FC-SW)", ANSI NCITS 321-1998, 1998. "Fibre Channel - Switch Fabric (FC-SW)", ANSI NCITS 321-1998, 1998.
[FC-SW2] [FC-SW2]
"Fibre Channel - Switch Fabric - 2 (FC-SW-2)", T11/Project "Fibre Channel - Switch Fabric - 2 (FC-SW-2)", T11/Project
1305D/Rev 5.3, ANSI NCITS xxx-200x, June 2001. 1305D/Rev 5.3, ANSI NCITS xxx-200x, June 2001.
10. Informative References
[RFC2741]
Daniele, M., Wijnen, B., Ellison, M., and D. Francisco. "Agent
Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[RFC2837]
Teow, K., "Definitions of Managed Objects for the Fabric Element in
Fibre Channel Standard", RFC 2837, May 2000.
[RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and
Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[WWN1] [WWN1]
Snively, R., "New identifier formats based on IEEE registration", Snively, R., "New identifier formats based on IEEE registration",
http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html, http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html,
16 January 2001. 16 January 2001.
[WWN2] [WWN2]
Snively, R., "Use of the IEEE Registration Authority assigned Snively, R., "Use of the IEEE Registration Authority assigned
'company_id' with the ANSI X3.230 FC-PH Fibre Channel specification 'company_id' with the ANSI X3.230 FC-PH Fibre Channel specification
and its extensions", and its extensions",
http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html, http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html,
24 February 1997. 24 February 1997.
[SENSOR] [SENSOR]
Bierman, A., Romascanu, D., and KC Norseth, "Entity Sensor Bierman, A., Romascanu, D., and KC Norseth, "Entity Sensor
Management Information Base", Internet Draft, <draft-ietf-entmib- Management Information Base", Internet Draft, working draft, 16
sensor-mib-00.txt>, 18 January 2002. October 2002.
10. Security Considerations 11. Security Considerations
There are a number of management objects defined in this MIB that have a There are a number of management objects defined in this MIB that have a
MAX-ACCESS clause of read-write. Such objects may be considered MAX-ACCESS clause of read-write:
sensitive or vulnerable in some network environments. The support for
SET operations in a non-secure environment without proper protection can fcmInstanceTextName
fcmInstanceDescr
fcmSwitchDomainId
fcmPortAdminType
fcmPortAdminSpeed
fcmISPortClassFCredit
Such objects may be considered sensitive or vulnerable in some network
environments. For example, the ability to change network topology or
network speed may afford an attacker the ability to obtain better
performance at the expense of other network users. The support for SET
operations in a non-secure environment without proper protection can
have a negative effect on network operations. have a negative effect on network operations.
There are a number of managed objects in this MIB that contain what Some of the readable objects in this MIB module (i.e., objects with a
could be considered as sensitive information. In particular, the MAX-ACCESS other than not-accessible) may be considered sensitive or
objects which provide information on network topology: vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly to
even encrypt the values of these objects when sending them over the
network via SNMP. In particular, these objects provide information on
network topology:
fcmLinkEnd1NodeWwn fcmLinkEnd1NodeWwn
fcmLinkEnd1PhysPortNumber fcmLinkEnd1PhysPortNumber
fcmLinkEnd1PortWwn fcmLinkEnd1PortWwn
fcmLinkEnd2NodeWwn fcmLinkEnd2NodeWwn
fcmLinkEnd2PhysPortNumber fcmLinkEnd2PhysPortNumber
fcmLinkEnd2PortWwn fcmLinkEnd2PortWwn
fcmLinkEnd2AgentAddress fcmLinkEnd2AgentAddress
fcmLinkEnd2PortType fcmLinkEnd2PortType
fcmLinkEnd2UnitType fcmLinkEnd2UnitType
fcmLinkEnd2FcAddressId fcmLinkEnd2FcAddressId
Therefore, it may be important in some environments to control read SNMP versions prior to SNMPv3 did not include adequate security. Even
access to these objects and possibly to even encrypt their values when if the network itself is secure (for example by using IPSec), even then,
sending them over the network via SNMP. Not all versions of SNMP there is no control as to who on the secure network is allowed to access
provide features for such a secure environment. and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv1 by itself is not a secure environment. Even if the network It is RECOMMENDED that implementors consider the security features as
itself is secure (for example by using IPSec), even then, there is no provided by the SNMPv3 framework (see [RFC3410], section 8), including
control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB.
It is recommended that the implementors consider the security features full support for the SNMPv3 cryptographic mechanisms (for authentication
as provided by the SNMPv3 framework. Specifically, the use of the User- and privacy).
based Security Model RFC 2574 [RFC2574] and the View-based Access
Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.
giving access to an instance of this MIB, is properly configured to give Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic
access to the objects only to those principals (users) that have security. It is then a customer/operator responsibility to ensure that
legitimate rights to indeed GET or SET (change/create/delete) them. the SNMP entity giving access to an instance of this MIB module is
properly configured to give access to the objects only to those
principals (users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
11. Comparison to draft-ietf-ipfc-fcmgmt-int-mib-07.txt 12. Comparison to draft-ietf-ipfc-fcmgmt-int-mib-07.txt
11.1. Problems with draft-ietf-ipfc-fcmgmt-int-mib-07.txt 12.1. Problems with draft-ietf-ipfc-fcmgmt-int-mib-07.txt
The Fibre Channel Management Integration MIB had the following major The Fibre Channel Management Integration MIB had the following major
problems: problems:
- It wasn't formatted using SMIv2, which is mandatory. - It wasn't formatted using SMIv2, which is mandatory.
- The MIB seemed to have been defined with the notion that it would - The MIB seemed to have been defined with the notion that it would
be the only MIB that a Fibre Channel product will require. The be the only MIB that a Fibre Channel product will require. The
notion of an agent implementing just a single MIB was abandoned by notion of an agent implementing just a single MIB was abandoned by
the IETF in 1992 as being non-scaleable. Rather, a Fibre Channel the IETF in 1992 as being non-scaleable. Rather, a Fibre Channel
skipping to change at page 70, line 5 skipping to change at page 69, line 5
management. SNMP agents need to implement a row in the ifTable for management. SNMP agents need to implement a row in the ifTable for
each of their network interfaces, including their Fibre Channel each of their network interfaces, including their Fibre Channel
interfaces. The IF-MIB requires a media-specific MIB to specify interfaces. The IF-MIB requires a media-specific MIB to specify
how that type of interface uses the ifTable (see section 4 in RFC how that type of interface uses the ifTable (see section 4 in RFC
2863). RFC 2837 doesn't do that, and nor did the Fibre Channel 2863). RFC 2837 doesn't do that, and nor did the Fibre Channel
Integration MIB. Integration MIB.
- It incorrectly used the OCTET STRING syntax (instead of Counter32 - It incorrectly used the OCTET STRING syntax (instead of Counter32
or Counter64) for counters. or Counter64) for counters.
11.2. Detailed Changes 12.2. Detailed Changes
11.2.1. Removal of Sensor-related objects 12.2.1. Removal of Sensor-related objects
Information about sensors is not specific to Fibre Channel, and Information about sensors is not specific to Fibre Channel, and
therefore should not be in this MIB. (At the time of writing, the the therefore should not be in this MIB. (At the time of writing, the the
IETF's ENTITY MIB Working Group has produced a first draft of a Sensor IETF's ENTITY MIB Working Group has produced a first draft of a Sensor
MIB, see [SENSOR].) This removed the need for: MIB, see [SENSOR].) This removed the need for:
connUnitSensorTable (and all its contents) connUnitSensorTable (and all its contents)
connUnitNumSensors connUnitNumSensors
connUnitSensorStatusChange connUnitSensorStatusChange
11.2.2. Removal of Trap-registration objects 12.2.2. Removal of Trap-registration objects
Information about registering "traps" is not specific to Fibre Channel, Information about registering "traps" is not specific to Fibre Channel,
and therefore should not be in this MIB. (For similar functionality, and therefore should not be in this MIB. (For similar functionality,
see SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB in RFC 2573). This see SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB in RFC 2573). This
removed the need for: removed the need for:
trapMaxClients trapMaxClients
trapClientCount trapClientCount
trapRegTable (and all its contents) trapRegTable (and all its contents)
11.2.3. Removal of Event-related objects 12.2.3. Removal of Event-related objects
Information about generic events is not specific to Fibre Channel, and Information about generic events is not specific to Fibre Channel, and
therefore should not be in this MIB. (For similar functionality, see therefore should not be in this MIB. (For similar functionality, see
the Event group in RFC 2819 and the Notification Log MIB in RFC 3014; the Event group in RFC 2819 and the Notification Log MIB in RFC 3014;
the SNMP-NOTIFICATION-MIB provides for the filtering of notifications.) the SNMP-NOTIFICATION-MIB provides for the filtering of notifications.)
This removed the need for: This removed the need for:
connUnitEventTable (and all its contents) connUnitEventTable (and all its contents)
connUnitEventFilter connUnitEventFilter
connUnitNumEvents connUnitNumEvents
connUnitMaxEvents connUnitMaxEvents
connUnitEventCurrID connUnitEventCurrID
connUnitEventTrap connUnitEventTrap
11.2.4. Removal of inventory-related information 12.2.4. Removal of inventory-related information
Aspects of hardware (physical) components are represented in the Entity Aspects of hardware (physical) components are represented in the Entity
MIB (RFC 2737); aspects of software modules are represented in the Host MIB (RFC 2737); aspects of software modules are represented in the Host
Resources MIB (RFC 2790). Two new objects provide indexing from this Resources MIB (RFC 2790). Two new objects provide indexing from this
MIB into those MIBs: one having the value of PhysicalIndex (or zero) and MIB into those MIBs: one having the value of PhysicalIndex (or zero) and
the other having the value of hrSWInstalledIndex (or zero). These the other having the value of hrSWInstalledIndex (or zero). These
replaced the need for: replaced the need for:
connUnitNumports connUnitNumports
connUnitRevsTable (and all its contents) connUnitRevsTable (and all its contents)
connUnitNumRevs connUnitNumRevs
connUnitPortRevision connUnitPortRevision
connUnitPortVendor connUnitPortVendor
connUnitProduct connUnitProduct
connUnitInfo connUnitInfo
connUnitSn connUnitSn
connUnitModuleId connUnitModuleId
connUnitVendorId connUnitVendorId
connUnitDeletedTrap connUnitDeletedTrap
11.2.5. Removal of revision numbers 12.2.5. Removal of revision numbers
The forward/backward compatibility rules of how to evolve MIBs are The forward/backward compatibility rules of how to evolve MIBs are
designed such that MIBs do not have revision numbers. This removed the designed such that MIBs do not have revision numbers. This removed the
need for: need for:
revisionNumber revisionNumber
11.2.6. Removal of other not FC-specific information 12.2.6. Removal of other not FC-specific information
Other information was removed because it was not specific to Fibre Other information was removed because it was not specific to Fibre
Channel: Channel:
systemURL systemURL
statusChangeTime statusChangeTime
configurationChangeTime configurationChangeTime
connUnitUrl connUnitUrl
connUnitUpTime connUnitUpTime
connUnitState connUnitState
connUnitContact connUnitContact
connUnitLocation connUnitLocation
connUnitProxyMaster connUnitProxyMaster
connUnitControl connUnitControl
connUnitStatus connUnitStatus
connUnitStatusChange connUnitStatusChange
11.2.7. Clean-up of ambiguous/obsolete definitions 12.2.7. Clean-up of ambiguous/obsolete definitions
Some information in the FC Management integration was obsolete or Some information in the FC Management integration was obsolete or
ambiguous: ambiguous:
statusChangeTime (obsolete) statusChangeTime (obsolete)
configurationChangeTime (obsolete) configurationChangeTime (obsolete)
connUnitTableChangeTime (obsolete) connUnitTableChangeTime (obsolete)
connUnitStatusChangeTime (obsolete) connUnitStatusChangeTime (obsolete)
connUnitConfigurationChangeTime (obsolete) connUnitConfigurationChangeTime (obsolete)
connUnitNumZones (obsolete) connUnitNumZones (obsolete)
connUnitZoneTable (referenced but not defined) connUnitZoneTable (referenced but not defined)
connUnitLinkCurrIndex (badly defined) connUnitLinkCurrIndex (badly defined)
11.2.8. Use of an ifTable entry 12.2.8. Use of an ifTable entry
The following objects were removed because they duplicated existing IF- The following objects were removed because they duplicated existing IF-
MIB objects: MIB objects:
redundant object existing object(s) redundant object existing object(s)
---------------- ------------------ ---------------- ------------------
connUnitPortStatCountError ifInErrors & ifOutErrors connUnitPortStatCountError ifInErrors & ifOutErrors
connUnitPortStatCountTxObjects ifOutUcastPkts & connUnitPortStatCountTxObjects ifOutUcastPkts &
ifHCOutUcastPkts ifHCOutUcastPkts
connUnitPortStatCountRxObjects ifInUcastPkts & connUnitPortStatCountRxObjects ifInUcastPkts &
skipping to change at page 73, line 13 skipping to change at page 72, line 13
connUnitPortFCId ifPhysAddress connUnitPortFCId ifPhysAddress
connUnitPortControl ifAdminStatus connUnitPortControl ifAdminStatus
connUnitPortState ifAdminStatus connUnitPortState ifAdminStatus
connUnitPortHWState ifOperStatus connUnitPortHWState ifOperStatus
connUnitPortStatus ifOperStatus connUnitPortStatus ifOperStatus
connUnitPortName ifAlias connUnitPortName ifAlias
connUnitPortStatObject ifSpecific connUnitPortStatObject ifSpecific
connUnitNumports ifNumber connUnitNumports ifNumber
connUnitPortStatusChange linkUp/linkDown connUnitPortStatusChange linkUp/linkDown
11.2.9. Removed because of AgentX difficulty 12.2.9. Removed because of AgentX difficulty
An Agentx environment [RFC2741] consists of a master agent and several An AgentX environment [RFC2741] consists of a master agent and several
sub-agents. It is not difficult to implement the same MIB in several sub-agents. It is not difficult to implement the same MIB in several
such sub-agents if all of the MIB's tables have a common index variable such sub-agents if all of the MIB's tables have a common index variable
as the first auxiliary object in their INDEX clauses. However, any as the first auxiliary object in their INDEX clauses. However, any
scalars which the MIB contains pose a problem for the AgentX scalars which the MIB contains pose a problem for the AgentX
environment. All the (remaining) scalars were therefore removed: environment. All the (remaining) scalars were therefore removed:
revisionNumber revisionNumber
uNumber uNumber
systemURL systemURL
11.2.10. FC Management Instance 12.2.10. FC Management Instance
The term "connectivity unit" was changed to "FC management instance". The term "connectivity unit" was changed to "FC management instance".
The term "connectivity unit" was not properly defined in draft-ietf- The term "connectivity unit" was not properly defined in draft-ietf-
ipfc-fcmgmt-int-mib-07.txt, and its usage provided a confused mixture of ipfc-fcmgmt-int-mib-07.txt, and its usage provided a confused mixture of
indications to the implementor: indications to the implementor:
- the definition of FcUnitType suggested it was functional; - the definition of FcUnitType suggested it was functional;
- the definition of uNumber suggested it was physical; - the definition of uNumber suggested it was physical;
- the definition of connUnitProduct suggested it was a vendor's product; - the definition of connUnitProduct suggested it was a vendor's product;
skipping to change at page 74, line 9 skipping to change at page 73, line 9
In fact, this scenario is not new; in practice, a "connectivity unit" In fact, this scenario is not new; in practice, a "connectivity unit"
will have the same semantics as a management "instance" in other MIBs, will have the same semantics as a management "instance" in other MIBs,
e.g., the IPS WG's own iSCSI MIB. For this MIB, its meaning is: "a e.g., the IPS WG's own iSCSI MIB. For this MIB, its meaning is: "a
separable managed instance of Fibre Channel functionality". Given this separable managed instance of Fibre Channel functionality". Given this
definition, then "FC management instance" is a better name because it is definition, then "FC management instance" is a better name because it is
more accurate and more representative of the definition, than is more accurate and more representative of the definition, than is
"connectivity unit". "connectivity unit".
11.2.11. Counter Syntax 12.2.11. Counter Syntax
All packet and octet counters have been changed to be Counter64's (but All packet and octet counters have been changed to be Counter64's (but
Counter32 versions of them are also included for use by old agents). Counter32 versions of them are also included for use by old agents).
The error counters have been changed to Counter32's. (In the probably The error counters have been changed to Counter32's. (In the probably
impossible, and at most improbable, circumstances that the rate of impossible, and at most improbable, circumstances that the rate of
occurence of errors, even on a 10Gbs Fibre Channel interface, might wrap occurrence of errors, even on a 10Gbs Fibre Channel interface, might
faster than a hour, the fact that errors are occurring will almost wrap faster than a hour, the fact that errors are occurring will almost
certainly be apparent from other MIB objects.) certainly be apparent from other MIB objects.)
11.2.12. Obsolete/Little-Used Fibre Channel features 12.2.12. Obsolete/Little-Used Fibre Channel features
Information relating to Fibre Channel features which are obsolete or not Information relating to Fibre Channel features which are obsolete or not
widely-implemented has been deleted. (For more information, see section widely-implemented has been deleted. (For more information, see section
6.2.1 and section 6.2.2 of [FC-MI].) 6.2.1 and section 6.2.2 of [FC-MI].)
- Class 1 service, - Class 1 service,
- Intermix Mode, - Intermix Mode,
- Stacked Conn Mode. - Stacked Conn Mode.
- PH version numbers - PH version numbers
skipping to change at page 74, line 42 skipping to change at page 73, line 42
longer need to be counted for all classes as well as for class 2, and longer need to be counted for all classes as well as for class 2, and
therefore these objects: therefore these objects:
connUnitPortStatCountFBSYFrames connUnitPortStatCountFBSYFrames
connUnitPortStatCountPBSYFrames connUnitPortStatCountPBSYFrames
connUnitPortStatCountFRJTFrames connUnitPortStatCountFRJTFrames
connUnitPortStatCountPRJTFrames connUnitPortStatCountPRJTFrames
have been deleted. have been deleted.
11.3. Name Server objects 12.3. Name Server objects
A table of Name Server information was present in draft-ietf-ipfc- A table of Name Server information was present in draft-ietf-ipfc-
fcmgmt-int-mib-07.txt. That information is not currently represented in fcmgmt-int-mib-07.txt. That information is not currently represented in
this MIB, because this MIB is already quite large, and a set of Name this MIB, because this MIB is already quite large, and a set of Name
Server objects are expected to be defined in a separate (new) MIB. Server objects are expected to be defined in a separate (new) MIB.
11.4. Additional objects 12.4. Additional objects
Support for Class F traffic, including 32-bit octet and frame counters, Support for Class F traffic, including 32-bit octet and frame counters,
has been added. has been added.
12. Comparison to RFC 2837 13. Comparison to RFC 2837
This MIB is a superset of RFC 2837, except for the following: This MIB is a superset of RFC 2837, except for the following:
- the fcFeClass1AccountingGroup group is obsolete, - the fcFeClass1AccountingGroup group is obsolete,
- fcFxPortConnectedNxPort, fcFxPortFcphVersionHigh, - fcFxPortConnectedNxPort, fcFxPortFcphVersionHigh,
fcFxPortFcphVersionLow, fcFxPortFcphVersionAgreed, fcFxPortFcphVersionLow, fcFxPortFcphVersionAgreed,
fcFxPortStackedConnModeAgreed, fcFxPortIntermixSuppAgreed, fcFxPortStackedConnModeAgreed, fcFxPortIntermixSuppAgreed,
fcFxPortCapStackedConnMode and fcFxPortCapIntermix are obsolete, fcFxPortCapStackedConnMode and fcFxPortCapIntermix are obsolete,
- fcFxPortBbCredit and fcFxPortRxBufSize are per attached Nx_Port, - fcFxPortBbCredit and fcFxPortRxBufSize are per attached Nx_Port,
- fcFxPortBbCreditAvailable is ephemeral, - fcFxPortBbCreditAvailable is ephemeral,
- fcFeModuleTable is mostly contained in the entPhysicalTable, - fcFeModuleTable is mostly contained in the entPhysicalTable,
- fcFxPortPhysAdminStatus, fcFxPortPhysOperStatus, and - fcFxPortPhysAdminStatus, fcFxPortPhysOperStatus, and
fcFxPortPhysLastChange have equivalents in the ifTable. fcFxPortPhysLastChange have equivalents in the ifTable.
13. Author's Address 14. Author's Address
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA USA 95134 San Jose, CA USA 95134
Phone: +1 408-526-5260 Phone: +1 408-526-5260
Email: kzm@cisco.com Email: kzm@cisco.com
14. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/