among mutually consenting parties.
Values in this range extend from 10,000 to 99,999. IANA will not
make any allocations from this range.
3) values larger than 99,999 are RESERVED.
12. Comparison to the Fibre Channel Management Integration MIB
12.1. Problems with the Fibre Channel Management Integration MIB
The Fibre Channel Management Integration MIB [MIB-FA] had the
following major problems:
- It wasn’t formatted using SMIv2, which is mandatory.
- 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
notion of an agent implementing just a single MIB was abandoned by
the IETF in 1992 as being non-scalable. Rather, a Fibre Channel
MIB needed to be another MIB in the continuing series of MIBs
defined by the IETF, and thus, it needed to be consistent with its
predecessors. In other words, there are existing MIBs that all
SNMP agents must support, even if the support of Fibre Channel
interfaces is the only functionality that they have. Thus, it was
essential that the Fibre Channel Integration MIB contained only
objects for information that is specific to Fibre Channel. All
objects relevant to non-Fibre Channel environments needed to be
removed. This issue applied to a large fraction of the objects
defined in the MIB.
- The MIB had some but not complete overlap in functionality with
RFC 2837.
- Every SNMP agent must implement the ifTable. The ifTable counters
are the MIB objects most well-used by administrators in SNMP
management. SNMP agents need to implement a row in the ifTable
for each of their network interfaces, including their Fibre
Channel interfaces. The IF-MIB requires a media-specific MIB to
specify how that type of interface uses the ifTable (see section 4
in RFC 2863). [RFC2837] doesn’t do that, nor did the Fibre
Channel Integration MIB.
- It incorrectly used the OCTET STRING syntax (instead of Counter32
or Counter64) for counters.
12.2. Detailed Changes
12.2.1. Removal of Sensor-Related Objects
Information about sensors is not specific to Fibre Channel, and
therefore should not be in this MIB. (At the time of writing, the
IETF’s ENTITY MIB Working Group has produced a first draft of a
Sensor MIB, see [RFC3433].) This removed the need for:
connUnitSensorTable (and all its contents)
connUnitNumSensors
connUnitSensorStatusChange
12.2.2. Removal of Trap-registration Objects
Information about registering "traps" is not specific to Fibre
Channel, and therefore should not be in this MIB. (For similar
functionality, see SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB in RFC
2573). This removed the need for:
trapMaxClients
trapClientCount
trapRegTable (and all its contents)
12.2.3. Removal of Event-Related Objects
Information about generic events is not specific to Fibre Channel,
and 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 SNMP-NOTIFICATION-MIB provides for the filtering of
notifications.) This removed the need for:
connUnitEventTable (and all its contents)
connUnitEventFilter
connUnitNumEvents
connUnitMaxEvents
connUnitEventCurrID
connUnitEventTrap
12.2.4. Removal of Inventory-Related Information
Aspects of hardware (physical) components are represented in the
Entity MIB (RFC 2737); aspects of software modules are represented in
the Host Resources MIB (RFC 2790). Two new objects provide indexing
from this MIB into those MIBs: one having the value of PhysicalIndex
(or zero) and the other having the value of hrSWInstalledIndex (or
zero). These replaced the need for:
connUnitNumports
connUnitRevsTable (and all its contents)
connUnitNumRevs
connUnitPortRevision
connUnitPortVendor
connUnitProduct
connUnitInfo
connUnitSn
connUnitModuleId
connUnitVendorId
connUnitDeletedTrap
12.2.5. Removal of Revision Numbers
The forward/backward compatibility rules of how to evolve MIBs are
designed such that MIBs do not have revision numbers. This removed
the need for:
revisionNumber
12.2.6. Removal of Other Not FC-Specific Information
Other information was removed because it was not specific to Fibre
Channel:
systemURL
statusChangeTime
configurationChangeTime
connUnitUrl
connUnitUpTime
connUnitState
connUnitContact
connUnitLocation
connUnitProxyMaster
connUnitControl
connUnitStatus
connUnitStatusChange
12.2.7. Clean-up of Ambiguous/Obsolete Definitions
Some information in the FC Management integration was obsolete or
ambiguous:
statusChangeTime (obsolete)
configurationChangeTime (obsolete)
connUnitTableChangeTime (obsolete)
connUnitStatusChangeTime (obsolete)
connUnitConfigurationChangeTime (obsolete)
connUnitNumZones (obsolete)
connUnitZoneTable (referenced but not defined)
connUnitLinkCurrIndex (badly defined)
12.2.8. Use of an ifTable Entry
The following objects were removed because they duplicated existing
IF-MIB objects:
redundant object existing object(s)
---------------- ------------------
connUnitPortStatCountError ifInErrors & ifOutErrors
connUnitPortStatCountTxObjects ifOutUcastPkts &
ifHCOutUcastPkts
connUnitPortStatCountRxObjects ifInUcastPkts &
ifHCInUcastPkts
connUnitPortStatCountTxElements ifOutOctets &
ifHCOutOctets
connUnitPortStatCountRxElements ifInOctets &
ifHCInOctets
connUnitPortStatCountRxMulticastObjects
ifInMulticastPkts &
ifHCInMulticastPkts
connUnitPortStatCountTxMulticastObjects
ifOutMulticastPkts &
ifHCOutMulticastPkts
connUnitPortStatCountRxBroadcastObjects
ifInBroadcastPkts &
ifHCInBroadcastPkts
connUnitPortStatCountTxBroadcastObjects
ifOutBroadcastPkts &
ifHCOutBroadcastPkts
connUnitPortFCId ifPhysAddress
connUnitPortControl ifAdminStatus
connUnitPortState ifAdminStatus
connUnitPortHWState ifOperStatus
connUnitPortStatus ifOperStatus
connUnitPortName ifAlias
connUnitPortStatObject ifSpecific
connUnitNumports ifNumber
connUnitPortStatusChange linkUp/linkDown
12.2.9. Removed Because of AgentX Difficulty
An AgentX environment [RFC2741] consists of a master agent and
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 as the first auxiliary object in their INDEX clauses.
However, any scalars that the MIB contains pose a problem for the
AgentX environment. All the (remaining) scalars were therefore
removed:
revisionNumber
uNumber
systemURL
12.2.10. FC Management Instance
The term "connectivity unit" was changed to "FC management instance".
The term "connectivity unit" was not properly defined in [MIB-FA],
and its usage provided a confused mixture of indications to the
implementor:
- the definition of FcUnitType suggested it was functional;
- the definition of uNumber suggested it was physical;
- the definition of connUnitProduct suggested it was a vendor’s
product;
- etc.
The common implementation strategy for the "connectivity unit" was
which ever grouping provided access to the management functionality
the easiest. (One such grouping accommodates a single SNMP agent
having multiple AgentX [RFC2741] sub-agents, each supporting a
separate implementation of the MIB.)
In fact, this scenario is not new; in practice, a "connectivity unit"
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 separable managed instance of Fibre Channel functionality".
Given this definition, the "FC management instance" is a better name
because it is more accurate and more representative of the definition
than is "connectivity unit".
12.2.11. Counter Syntax
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). The error counters have been changed to Counter32’s. (In
the probably impossible, and at most improbable, circumstances that
the rate of occurrence of errors, even on a 10Gbs Fibre Channel
interface, might wrap faster than an hour, the fact that errors are
occurring will almost certainly be apparent from other MIB objects.)
12.2.12. Obsolete/Little-Used Fibre Channel Features
Information relating to Fibre Channel features that are obsolete or
not widely-implemented has been deleted. (For more information, see
section 6.2.1 and section 6.2.2 of [FC-MI].)
- Class 1 service,
- Intermix Mode,
- Stacked Conn Mode.
- PH version numbers
Note that with support for Class 1 service being deleted, only class
2 now needs F_BSY, F_RJT, P_BSY, and P_RJT counters, and thus they no
longer need to be counted for all classes as well as for class 2, and
therefore the following objects have been deleted:
connUnitPortStatCountFBSYFrames
connUnitPortStatCountPBSYFrames
connUnitPortStatCountFRJTFrames
connUnitPortStatCountPRJTFrames
12.3. Name Server Objects
A table of Name Server information was present in
the Fibre Channel Management Integration MIB [MIB-FA].
That information is not currently represented in 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.
12.4. Additional Objects
Support for Class F traffic, including 32-bit octet and frame
counters, has been added.
13. Comparison to RFC 2837
This MIB is a superset of RFC 2837, except for the following:
- the fcFeClass1AccountingGroup group is obsolete,
- fcFxPortConnectedNxPort, fcFxPortFcphVersionHigh,
fcFxPortFcphVersionLow, fcFxPortFcphVersionAgreed,
fcFxPortStackedConnModeAgreed, fcFxPortIntermixSuppAgreed,
fcFxPortCapStackedConnMode, and fcFxPortCapIntermix are obsolete,
- fcFxPortBbCredit and fcFxPortRxBufSize are per attached Nx_Port,
- fcFxPortBbCreditAvailable is ephemeral,
- fcFeModuleTable is mostly contained in the entPhysicalTable,
- fcFxPortPhysAdminStatus, fcFxPortPhysOperStatus, and
fcFxPortPhysLastChange have equivalents in the ifTable.
Author’s Address
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-526-5260
EMail: kzm@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.