RFC 4936
Fibre Channel Zone Server MIB
Pages: 84
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 23
Network Working Group C. DeSanti Request for Comments: 4936 H.K. Vivek Category: Standards Track K. McCloghrie Cisco Systems S. Gai Nuova Systems August 2007 Fibre Channel Zone Server MIB Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server.
Table of Contents
1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Overview of Fibre Channel .......................................3 3.1. General Overview ...........................................3 3.2. Zoning .....................................................4 3.3. Zoning Configuration and Management ........................5 4. Relationship to Other MIBs ......................................7 5. MIB Overview ....................................................8 5.1. Fibre Channel Management Instance ..........................8 5.2. Switch Index ...............................................8 5.3. Fabric Index ...............................................8 5.4. Locking the Fabric .........................................9 5.5. Basic and Enhanced Modes ..................................10 5.6. Persistent Storage ........................................10 5.7. The Active Zone Set and the Zone Set Database .............11 5.8. Conformance Groups ........................................12 6. The T11-FC-FABRIC-LOCK-MIB Module ..............................13 7. The T11-FC-ZONE-SERVER-MIB Module ..............................24 8. IANA Considerations ............................................79 9. Security Considerations ........................................79 10. Acknowledgements ..............................................80 11. Normative References ..........................................81 12. Informative References ........................................82
1. Introduction
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Zone Server. This memo was previously approved by INternational Committee for Information Technology Standards (INCITS) Task Group T11.5 (http://www.t11.org); this document is a product of the IETF's IMSS working group. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].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. Overview of Fibre Channel
3.1. General Overview
The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are
switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), 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. Many Fibre Channel components, including the Fabric, each node, and most ports, have globally unique names. These globally unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. For an Nx_Port, its WWN is called a N_Port_Name and its address identifier is called an N_Port_ID. When a Fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy.3.2. Zoning
Zones within a Fabric provide a mechanism to control frame delivery between Nx_Ports ("Hard Zoning") or to expose selected views of Name Server information ("Soft Zoning"). Communication is only possible when the communicating endpoints are members of a common zone. This technique is similar to virtual private networks in that the Fabric has the ability to group devices into Zones. Hard zoning and soft zoning are two different means of realizing this. Hard zoning is enforced in the Fabric (i.e., switches) whereas soft zoning is enforced at the endpoints (e.g., host bus adapters (HBAs)) by relying on the endpoints to not send traffic to an N_Port_ID not obtained from the Name Server with a few exceptions for well-known N_Port_IDs used to bootstrap the Fabric (e.g., talk to the Name Server). Administrators create Zones to increase network security and to prevent data loss or corruption by controlling access between devices or user groups. Zones may be specifically used to create:
a) Barriers between devices that use different operating systems.
It is often critical to separate servers and storage devices
with different operating systems because accidental transfer of
information from one to another may delete or corrupt data;
b) Logical subsets of closed user groups. Administrators may
authorize access rights to specific Zones for specific user
groups, thereby protecting confidential data from unauthorized
access;
c) Groups of devices that are separate from devices in the rest of
a Fabric. Zones allow certain processes to be performed on
devices in a group without interrupting devices in other
groups; or
d) Temporary access between devices for specific purposes.
Administrators may remove Zone restrictions temporarily, then
restore Zone restrictions to perform normal processes.
3.3. Zoning Configuration and Management
Zones are configured via a Fabric Zone Server, using requests defined
in [FC-GS-5]), or via the T11-FC-ZONE-SERVER-MIB module defined in
this memo, or via some other mechanism.
An Nx_Port may be a member of one or more Zones. Zone membership may
be specified by:
a) The N_Port_Name of the Nx_Port connected to the switch;
b) The N_Port_ID assigned during Fabric Login;
c) The Node_Name associated with the Nx_Port; note that the
Node_Name may include more than one Nx_Port;
d) The F_Port_Name of the Fx_Port to which the Nx_Port is
connected; or
e) The domain identifier (Domain_ID) and physical port number of
the Switch Port to which the Nx_Port is attached.
A Fabric's Zone Server may be used to create a Zone by specifying the
Zone Members. One or more Zones may be collected into a Zone Set,
and a Zone may be a member of more than one Zone Set. A Zone Set
creates a collection of Zones that may be activated or deactivated as
a single entity across all Switches in a Fabric (e.g., having two
Zone Sets, one for normal operation, and a second for backup during
off-hours). Only one Zone Set may be activated at one time.
Other terminology defined in [FC-GS-5] is: an Active Zone Set is the
Zone Set currently enforced by a Fabric; a Zone Set Database is a
database of the Zone Sets available to be activated within a Fabric;
and a Zoning Database is a generic term used to indicate a combination of an Active Zone Set and a Zone Set Database. Two distinct sets of management requests, Enhanced and Basic, are defined in [FC-GS-5] to interact with a Fabric Zone Server. Basic Zoning provides compatibility with [FC-GS-4] and earlier versions of Fibre Channel's Generic Services specification. If all the Switches in a Fabric support the Enhanced request set, then it may be used to manage zoning; otherwise, only the Basic request set may be used, in order to support backward compatibility. In the context of Enhanced Zoning Management, a management action (i.e., write access to the Zoning Database) to the Zone Server can only occur inside a server session. A server session is set up using the FC-GS-5's Common Transport (CT) protocol defined in [FC-GS-5]. A server session is delimited by CT protocol requests, Server Session Begin (SSB) and Server Session End (SSE), which are directed to the Management Service and which have the GS_Subtype specifying the Zone Server. Query requests that result in read access to the Zoning Database are not required to be issued inside a server session, although the information returned is not guaranteed to be consistent when supplied outside of a server session. When setting up a server session for Enhanced Zoning, the Zone Server is required to lock the Fabric. This ensures serialized management access to the Zoning Database and guarantees a deterministic behavior. The switch that receives the SSB request is called the 'managing' switch, and it tries to lock the Fabric using the Fabric Management Session Protocol (see section 10.6 of [FC-SW-4]) by sending an Acquire Change Authorization (ACA) request to all other switches in the Fabric. If any switch(es) respond with an SW_RJT indicating failure, then the attempt to lock the Fabric fails and the SSB request is rejected. If all the other switches respond with an SW_ACC indicating success, then the Fabric is locked and the server session can be established. The subsequent SSE request causes a Release Change Authorization (RCA) request to all other switches, and thus, the Fabric to be unlocked. For at least one application other than Zoning, the managing switch uses a different type of request to lock the Fabric, i.e., it sends an Enhanced Acquire Change Authorization (EACA) request to all other switches in the Fabric. An EACA reserves local resources associated with a designated application to ensure the consistency of that application's data. The application is identified in the EACA using an Application_ID (see Table 116 in [FC-SW-4]). A lock that was established via an EACA is released using an Enhanced Release Change Authorization (ERCA) request.
Changes requested in a Zoning Database by Enhanced Zoning commands persist after the end of the Zoning (server) session only if the commands are followed, within the same server session, by a Commit Zone Changes (CMIT) request. On receipt of a CMIT request, the Zone Server checks that the Zoning Database as modified by the outstanding changes will pass the applicable consistency checks, and then distributes it to all other switches in the Fabric using a Stage Fabric Configuration Update (SFC) request. If all other switches accept the SFC request, then the "managing" switch sends an Update Fabric Configuration (UFC) Request to each other switch, and the staged Zoning Database thereby becomes the Fabric's (active) Zoning Database. The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the earlier specification for the operation of a single Fabric in a physical infrastructure, and augments it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core switch.4. Relationship to Other MIBs
The Fibre Channel Management MIB [RFC4044] defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces. This MIB extends beyond [RFC4044] to cover the management of Fibre Channel Zoning Servers, both for Basic Zoning Management and for Enhanced Zoning Management, as defined in the FC-GS-5 specification. This MIB imports some common Textual Conventions from T11-TC-MIB, defined in [RFC4439]. It also imports a TC from T11-FC-NAME-SERVER- MIB, defined in [RFC4438], plus InetAddressType and InetAddress from INET-ADDRESS-MIB [RFC4001]. It also includes a reference to snmpCommunitySecurityName defined in [RFC3584].
5. MIB Overview
This document defines two MIB modules: T11-FC-FABRIC-LOCK-MIB and T11-FC-ZONE-SERVER-MIB. T11-FC-FABRIC-LOCK-MIB supports FC-GS-5's generic capability of locking the Fabric for a particular "application" such as (the management of) Enhanced Zoning. The MIB contains one table in which each entry represents a particular switch being the 'managing' switch of a particular application's Fabric lock. T11-FC-ZONE-SERVER-MIB is specific to the operation of Zone Servers, which can operate in Basic mode or in Enhanced mode. This MIB module imports the T11NsGs4RejectReasonCode textual convention defined in T11-FC-NAME-SERVER-MIB [RFC4438].5.1. Fibre Channel Management Instance
A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example, within the same SNMP context ([RFC3411], section 3.3.1).5.2. Switch Index
The FC-MGMT-MIB [RFC4044] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value to uniquely identify a Fibre Channel switch amongst those (one or more) managed by the same Fibre Channel management instance.5.3. Fabric Index
Whether operating on a physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the operation of a Zone Server within a Fabric is identical. Therefore, this MIB defines all Fabric-related information in tables that are INDEXed by an arbitrary
integer, named a "Fabric Index", having the syntax, T11FabricIndex, which is IMPORTed from the T11-TC-MIB [RFC4439]. When a device is connected to a single physical Fabric, without use of any Virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before an object with FabricIndex as its syntax when both appear in the same INDEX clause.5.4. Locking the Fabric
The T11-FC-FABRIC-LOCK-MIB module provides for the management of locks on a Fibre Channel Fabric. A Fibre Channel Fabric lock is used to ensure serialized access to some types of management data related to a Fabric, e.g., the Fabric's Zoning Database. Some (managing) applications obtain a lock by initiating server sessions and the Fabric is locked so as to reserve local resources in each Switch. For this usage, the managing switch sends an Acquire Change Authorization (ACA) request to other switches in order to lock the Fabric. For some other applications, a managing switch locks the Fabric using an Enhanced Acquire Change Authorization (EACA) request, which identifies the application on whose behalf the Fabric is being locked with an Application_ID. In this case, only local resources associated with the designated application are reserved. Locks established via ACAs and via EACAs are both represented in the t11FLockTable in the T11-FC-FABRIC-LOCK-MIB. The Application_ID provided by the EACA serves to distinguish between multiple concurrent locks established by EACAs. In order to use this same mechanism to distinguish a lock established via an ACA from each of those established via EACAs, an additional (special) value of Application_ID has been assigned [APPL-ID] for use by this MIB module. Specifically, this newly assigned value will never be used to indicate an Application locked by an EACA, and therefore this MIB module uses it to uniquely distinguish a lock established via an ACA. In other words, with this additional assignment, an Application_ID value can be used to uniquely identify any active lock amongst all those established (on the same Fabric) either by an EACA or an ACA.
5.5. Basic and Enhanced Modes
The t11ZsServerOperationMode object indicates whether a Fabric's Zone Server is operating in Basic mode or Enhanced mode. These two modes have a sufficient amount of commonality to make it worthwhile to have one set of MIB objects that are used for the subset of functionality that is common to both modes. To accommodate the differences, additional MIB objects are defined. For Enhanced mode, the additional objects are defined in a group, t11ZsEnhancedModeGroup, which is only required to be implemented in a Zone Server capable of supporting Enhanced mode. The objects specific to Basic mode are always (even in Enhanced mode) expected to be implemented, but when in Enhanced mode, their values are either restricted or do not affect current operations, e.g., - an example of "restricted" is: the distribution of updates to the Zone Server database throughout the Fabric has to be requested explicitly in Basic mode; this functionality is provided in the MIB by the t11ZsServerDistribute object. In contrast, in Enhanced mode, the distribution is an implicit part of the commit function which is initiated using the t11ZsServerCommit object. Thus, when operating in Enhanced mode, t11ZsServerDistribute has a fixed value, and when operating in Basic mode, t11ZsServerCommit has a fixed value. - an example of "do not affect current operations" is: t11ZsServerHardZoning, which specifies whether a switch enforces hard Zoning on a Fabric when in Basic mode. This object is instantiated and could even be modified while in Enhanced mode, but its value only takes effect when in Basic mode. (Note that in Enhanced mode, t11ZsActiveZoneHardZoning specifies whether hard Zoning is enabled on a particular Zone.)5.6. Persistent Storage
A Zone Server Database for a given Fabric consists of the combination of many of the tables defined in this MIB module. In order to ensure that such a Database is consistent, this MIB module defines just one object (t11ZsServerDatabaseStorageType) with a syntax of StorageType, whose value for a given Fabric is defined to be applicable to all of that Fabric's Zone Server Database as defined in all the tables in this MIB module.
5.7. The Active Zone Set and the Zone Set Database
As described in FC-GS-5 [FC-GS-5], one of the Zone Sets in the Zone Set Database can be activated to become the Active Zone Set, i.e., the one which is enforced on the Fabric. Get/Add/Remove-type requests are defined in FC-GS-5 to allow access to the Zone Set Database. When the Zone Set Database is modified, such modifications don't affect the Active Zone Set unless and until a subsequent activation. Interaction directly with the Active Zone Set is also possible via the FC-GS-5 requests: 'Activate Direct' and 'Get Active Zone Set'. This is illustrated in the following rendition of Figure 15 of [FC-GS-5]: Zone Set Database +------------------+ | +--------------+ | Get | | Zone Set A | | <=========| |(zones, zone | | | | members,etc.)| | | +--------------+ | Add/ | | Zone Set B | | Activate +------------+ Remove | +------------+ | Zone Set | | =========>| |Zone Set C| |================>| | | +----------+ | | Active | +------------------+ | Zone | | Set | Get Active Zone Set | (enforced) | <==============================================| | | | Activate Direct | | ==============================================>| | | | Deactivate | | ==============================================>| | +------------+ The T11-FC-ZONE-SERVER-MIB module, defined in section 7, models the above structure by having one set of MIB tables for the Zone Set Database and a separate set for the Active Zone Set, specifically: - seven tables for the Zone Set Database: t11ZsSetTable, t11ZsZoneTable, t11ZsSetZoneTable, t11ZsAliasTable, t11ZsZoneMemberTable, t11ZsAttribBlockTable and t11ZsAttribTable. - four tables for the Active Zone Set: t11ZsActiveTable, t11ZsActiveZoneTable, t11ZsActiveZoneMemberTable and t11ZsActiveAttribTable.
5.8. Conformance Groups
5.8.1. The t11ZsBasicGroup
This group contains objects to retrieve and to modify the Zoning configuration of a Zone Server capable of operating in Basic mode.5.8.2. The t11ZsEnhancedModeGroup
This group contains objects to retrieve and to modify the Zoning configuration of a Zone Server capable of operating in Enhanced mode.5.8.3. The t11ZsActivateGroup
This group contains objects that allow a Zone Set to be activated via SNMP SetRequests and provide the status and result of such an activation.5.8.4. The t11ZsStatisticsGroup
This group contains objects for collecting Zone Server statistics.5.8.5. The t11ZsNotificationGroup
This group contains notifications for monitoring: Zone merge successes and failures, Zone Server request rejections, changes in the Default Zoning behavior, and the success or failure of an attempt to activate or deactivate a Zone Set.5.8.5.1. Flow-Control for Notifications
When defining SNMP notifications for events that occur in the data- plane, the maximum frequency of their generation needs to be considered. Unless there is some limiting factor, such notifications need to be flow-controlled in some way, e.g., defined such that after some maximum number have occurred within a specified time interval, further notifications are suppressed for some subsequent time interval. However, as and when such a suppression occurs, the Network Management System (NMS) that didn't receive the notifications (because they were suppressed) needs an indication of how many were suppressed. Therefore, an additional Counter32 object needs to be defined, and/or a new type of notification needs to be defined for use at the end of the interval. While this is extra complexity, it is necessary for notifications that need to be flow-controlled. In contrast, for notifications such as all those defined in this MIB module, which are generated due to control-plane events (and are not able to start a chain reaction):
- estimating the maximum number that could be generated per unit time
for each type of notification is too simplistic. For example, it's
unreasonable to ask how many of the t11ZsDefZoneChangeNotify
notifications can be generated in a time interval because it
depends on several factors: how many operators can be re-
configuring the network at the same time? and how frequently can
each of them change the Default Zone Setting?
- the extra complexity of flow-controlling these types of
notifications is not warranted.
5.8.6. The t11ZsNotificationControlGroup
This group contains objects that allow each type of notification (in
the t11ZsNotificationGroup group) to be independently enabled or
disabled. It also contains objects that are used to include useful
information in those notifications; these objects are defined as
read-only to allow the values contained in the most recent
notification to be queried.
6. The T11-FC-FABRIC-LOCK-MIB Module
T11-FC-FABRIC-LOCK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
mib-2 FROM SNMPv2-SMI -- [RFC2578]
RowStatus FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddressType, InetAddress FROM
INET-ADDRESS-MIB -- [RFC4001]
fcmInstanceIndex, fcmSwitchIndex FROM FC-MGMT-MIB -- [RFC4044]
T11NsGs4RejectReasonCode FROM
T11-FC-NAME-SERVER-MIB -- [RFC4438]
T11FabricIndex FROM T11-TC-MIB; -- [RFC4439]
t11FabricLockMIB MODULE-IDENTITY
LAST-UPDATED "200706270000Z"
ORGANIZATION "For the initial versions, T11.
For later versions, the IETF's IMSS Working Group."
CONTACT-INFO
" Claudio DeSanti
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134 USA
EMail: cds@cisco.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134 USA
EMail: kzm@cisco.com"
DESCRIPTION
"The MIB module for the management of locks on a Fibre
Channel Fabric. A Fibre Channel Fabric lock is used to
ensure serialized access to some types of management data
related to a Fabric, e.g., the Fabric's Zoning Database.
Some (managing) applications generate Fabric locks by
initiating server sessions. Server sessions are
defined generically in FC-GS-5 to represent a collection of
one or more requests to the session's server, e.g., to the
Zone Server. Such a session is started by a Server Session
Begin (SSB) request, and terminated by a Server Session End
(SSE) request. The switch receiving the SSB is called the
'managing' switch. Some applications require the
'managing' switch to lock the Fabric for the particular
application, e.g., for Enhanced Zoning, before it can
respond successfully to the SSB. On receipt of the
subsequent SSE, the lock is released. For this usage, the
managing switch sends an Acquire Change Authorization (ACA)
request to other switches to lock the Fabric.
For some other applications, a managing switch locks the
Fabric using an Enhanced Acquire Change Authorization (EACA)
request, which identifies the application on whose behalf
the Fabric is being locked with an Application_ID.
Fabric locks can also be requested more directly, e.g.,
through the use of this MIB. In these situations, the term
'managing' switch is used to indicate the switch that
receives such a request and executes it by issuing either
ACA or EACA requests to other switches in the Fabric.
This MIB module defines information about the 'managing'
switch for currently-active Fabric locks.
Copyright (C) The IETF Trust (2007). This version
of this MIB module is part of RFC 4936; see the RFC
itself for full legal notices."
REVISION "200706270000Z"
DESCRIPTION
"Initial version of this MIB module, published as RFC 4936."
::= { mib-2 159 }
t11FLockMIBObjects OBJECT IDENTIFIER ::= { t11FabricLockMIB 1 }
t11FLockMIBConformance OBJECT IDENTIFIER ::= { t11FabricLockMIB 2 }
t11FLockMIBNotifications OBJECT IDENTIFIER ::= { t11FabricLockMIB 0 }
t11FLockConfiguration OBJECT IDENTIFIER ::= { t11FLockMIBObjects 1 }
--
-- The table of Managing Switches and their Fabric Locks
--
t11FLockTable OBJECT-TYPE
SYNTAX SEQUENCE OF T11FLockEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about the 'managing'
switch of each current Fabric lock, e.g., for the
types of Servers defined in FC-GS-5.
Each entry in this table represents either:
1) a current Fabric lock,
2) an in-progress attempt, requested via SNMP, to set up
a lock, or
3) a failed attempt, requested via SNMP, to set up a lock.
If an entry is created via t11FLockRowStatus, but the
attempt to obtain the lock fails, then the entry continues
to exist until it is deleted via t11FLockRowStatus, or
it is overwritten by the lock being established via
a means other than SNMP. However, rows created via
t11FLockRowStatus are not retained over restarts."
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, sections 4.9.5 and 6.4.10.2."
::= { t11FLockConfiguration 1 }
t11FLockEntry OBJECT-TYPE
SYNTAX T11FLockEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains information specific to a current
Fabric lock set up by a particular 'managing' switch on a
particular Fabric. The 'managing switch' is identified by
values of fcmInstanceIndex and fcmSwitchIndex.
Server sessions for several different types of servers
are defined in FC-GS-5. The behavior of a server with
respect to commands received within a server session is
specified for each type of server. For some types,
parameter changes can only be made within the context of a
session, and the setting up of a session requires that the
Fabric be locked. A Fabric is locked by one switch, called
the 'managing' switch, sending Acquire Change Authorization
(ACA) requests to all other switches in the Fabric.
For other applications, a Fabric lock is established by the
'managing' switch sending Enhanced Acquire Change
Authorization (EACA) requests to other switches in the
Fabric. Each EACA request includes an Application_ID
value to identify the application requesting the lock.
For the benefit of this MIB module, a distinct value of
Application_ID has also been assigned/reserved (see
ANSI INCITS T11/06-679v0, titled 'FC-SW-5 Letter to
T11.5') as a means of distinguishing locks established via
Acquire Change Authorization (ACA) requests. This
additional assignment allows an Application_ID to be used to
uniquely identify any active lock amongst all those
established by either an EACA or an ACA.
Whenever a Fabric is locked, by the sending of either an ACA
or an EACA, a row gets created in the representation of this
table for the 'managing' switch.
In order to process SNMP SetRequests that make parameter
changes for the relevant types of servers (e.g., to the
Zoning Database), the SNMP agent must get serialized access
to the Fabric (for the relevant type of management data),
i.e., the Fabric must be locked by creating an entry in
this table via an SNMP SetRequest. Creating an entry in
this table via an SNMP SetRequest causes an ACA or an EACA
to be sent to all other switches in the Fabric. The value
of t11FLockApplicationID for such an entry determines
whether an ACA or an EACA is sent.
If an entry in this table is created by an SNMP SetRequest,
the value of the t11FLockInitiatorType object in that entry
will normally be 'snmp'. A row for which the value of
t11FLockInitiatorType is not 'snmp' cannot be modified
via SNMP. In particular, it cannot be deleted via
t11FLockRowStatus. Note that it's possible for a row to be
created by an SNMP SetRequest, but for the setup of the lock
to fail, and immediately thereafter be replaced by a lock
successfully set up by some other means; in such a case, the
value of t11FLockInitiatorType would change as and when the
lock was set up by the other means, and so the row could
not thereafter be deleted via t11FLockRowStatus.
FC-GS-5 mentions various error situations in which a
Fabric lock is released so as to avoid a deadlock. In
such situations, the agent removes the corresponding row
in this table as and when the lock is released. This can
happen for all values of t11FLockInitiatorType."
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, sections 4.9.5.5 and 6.4.7.1.
Fibre Channel - Switch Fabric-4 (FC-SW-4),
ANSI INCITS 418-2006, sections 6.1.17, 10.6.6, and 13.2,
and table 116.
'FC-SW-5 Letter to T11.5' ANSI INCITS T11/06-679v0,
http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf,
21 September 2006."
INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FLockFabricIndex,
t11FLockApplicationID }
::= { t11FLockTable 1 }
T11FLockEntry ::= SEQUENCE {
t11FLockFabricIndex T11FabricIndex,
t11FLockApplicationID OCTET STRING,
t11FLockInitiatorType INTEGER,
t11FLockInitiator OCTET STRING,
t11FLockInitiatorIpAddrType InetAddressType,
t11FLockInitiatorIpAddr InetAddress,
t11FLockStatus INTEGER,
t11FLockRejectReasonCode T11NsGs4RejectReasonCode,
t11FLockRejectReasonCodeExp OCTET STRING,
t11FLockRejectReasonVendorCode OCTET STRING,
t11FLockRowStatus RowStatus
}
t11FLockFabricIndex OBJECT-TYPE
SYNTAX T11FabricIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique index value that uniquely identifies a
particular Fabric.
In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics
can operate within one (or more) physical infrastructures,
and this index value is used to uniquely identify a
particular (physical or virtual) Fabric within a physical
infrastructure.
In a Fabric conformant to versions earlier than FC-SW-4,
only a single Fabric could operate within a physical
infrastructure, and thus, the value of this Fabric Index
was defined to always be 1."
::= { t11FLockEntry 1 }
t11FLockApplicationID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Application_ID value that identifies the type of
application for which the Fabric is locked.
A lock established via Acquire Change Authorization (ACA)
does not, strictly speaking, have an Application_ID value.
However, the value 'FF'h (255 decimal) has been reserved
by T11 to be used as the value of this MIB object as and
when a lock is established by an ACA. This value was
initially documented in a letter from the FC-SW-5 Editor
to T11.5, which was approved by the T11 and T11.5 plenary
meetings on October 5, 2006."
REFERENCE
"Fibre Channel - Switch Fabric-4 (FC-SW-4),
ANSI INCITS 418-2006, April 2006, Table 116.
'FC-SW-5 Letter to T11.5' ANSI INCITS T11/06-679v0,
http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf,
21 September 2006."
::= { t11FLockEntry 2 }
t11FLockInitiatorType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
ssb(2),
cli(3),
snmp(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies what type of initiator generated
the request that caused this lock to be established:
other - none of the following.
ssb - this lock was established due to the
receipt of an SSB, e.g., from a GS-5
client.
cli - this lock was established in order
to process a Command Line Interface
(CLI) command.
snmp - this lock was established as a result
of an SNMP SetRequest.
"
::= { t11FLockEntry 3 }
t11FLockInitiator OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..64))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the initiator whose request
caused this lock to be established.
If the value of the corresponding instance
of t11FLockInitiatorType is 'ssb', this
object will contain the FC_ID of the client
that issued the Server Session Begin (SSB)
that required the lock to be established.
If the value of the corresponding instance
of t11FLockInitiatorType object is 'cli', this
object will contain the user name of the CLI
(Command Line Interface) user on whose behalf
the lock was established.
If the value of the corresponding instance of
t11FLockInitiatorType is 'snmp', this object
will contain the SNMP securityName used by the
SNMPv3 message containing the SetRequest that
created this row. (If the row was created via
SNMPv1 or SNMPv2c, then the appropriate value of
the snmpCommunitySecurityName is used.)"
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, section 4.9.5.2.
SNMP securityName is defined in RFC 3411, 'An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks'.
snmpCommunitySecurityName is defined in RFC 3584,
'Coexistence between Version 1, Version 2, and
Version 3 of the Internet-standard Network
Management Framework.'"
::= { t11FLockEntry 4 }
t11FLockInitiatorIpAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the type of IP address contained
in the corresponding instance of t11FLockInitiatorIpAddr.
If the IP address of the location of the initiator is
unknown or not applicable, this object has the value:
'unknown'."
::= { t11FLockEntry 5 }
t11FLockInitiatorIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the IP address of the location
of the initiator that established this lock via a
request of the type given by the corresponding instance
of t11FLockInitiatorType. In cases where the
corresponding instance of t11FLockInitiatorIpAddrType has
the value: 'unknown', the value of this object is the
zero-length string."
::= { t11FLockEntry 6 }
t11FLockStatus OBJECT-TYPE
SYNTAX INTEGER {
active(1),
settingUp(2),
rejectFailure(3),
otherFailure(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object gives the current status of the lock:
'active' -- the lock is currently established.
'settingUp' -- the 'managing' switch is currently
attempting to set up the lock, e.g.,
it is waiting to receive Accepts
for ACAs from every switch in the
Fabric.
'rejectFailure' -- the 'managing' switch's attempt to
set up the lock was rejected with
the reason codes given by:
t11FLockRejectReasonCode,
t11FLockRejectReasonCodeExp and
t11FLockRejectReasonVendorCode.
'otherFailure' -- the 'managing' switch's attempt
to set up the lock failed (but no
reason codes are available).
For values of t11FLockInitiatorType other than 'snmp',
a row is only required to be instantiated in this table
when the value of this object is 'active'.
If the value of the corresponding instance of
t11FLockInitiatorType is 'snmp', the initial value of this
object when the row is first created is 'settingUp'. As
and when the setup succeeds, the value transitions to
'active'. If the setup fails, the value transitions to
either 'rejectFailure' or 'otherFailure'. Note that such a
failure value is overwritten on the next attempt to obtain
the lock, which could be immediately after the failure,
e.g., by a GS-5 client.
When the value of this object is 'rejectFailure', the
rejection's reason codes are given by the corresponding
values of t11FLockRejectReasonCode,
t11FLockRejectReasonCodeExp and
t11FLockRejectReasonVendorCode."
::= { t11FLockEntry 7 }
t11FLockRejectReasonCode OBJECT-TYPE
SYNTAX T11NsGs4RejectReasonCode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When the value of the corresponding instance of
t11FLockStatus is 'rejectFailure', this object contains
the rejection's reason code."
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, section 4.4.4 and table 10."
::= { t11FLockEntry 8 }
t11FLockRejectReasonCodeExp OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0 | 1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When the value of the corresponding instance of
t11FLockStatus is 'rejectFailure', this object contains
the rejection's reason code explanation."
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, sections 4.4.4 and 6.4.9,
tables 10 and 252."
::= { t11FLockEntry 9 }
t11FLockRejectReasonVendorCode OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0 | 1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When the value of the corresponding instance of
t11FLockStatus is 'rejectFailure', this object contains
the rejection's vendor-specific code."
REFERENCE
"Fibre Channel - Generic Services-5 (FC-GS-5),
ANSI INCITS 427-2007, section 4.4.4."
::= { t11FLockEntry 10 }
t11FLockRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row.
A row in this table can be modified or deleted via
this object only when the row's value of
t11FLockInitiatorType is 'snmp'."
::= { t11FLockEntry 11 }
-- Conformance
t11FLockMIBCompliances
OBJECT IDENTIFIER ::= { t11FLockMIBConformance 1 }
t11FLockMIBGroups OBJECT IDENTIFIER ::= { t11FLockMIBConformance 2 }
t11FLockMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for entities that support
Fabric locks in support of GS-5 Server applications."
MODULE MANDATORY-GROUPS { t11FLockActiveGroup }
OBJECT t11FLockRowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { t11FLockMIBCompliances 1 }
-- Units of Conformance
t11FLockActiveGroup OBJECT-GROUP
OBJECTS { t11FLockInitiatorType,
t11FLockInitiator,
t11FLockInitiatorIpAddrType,
t11FLockInitiatorIpAddr,
t11FLockStatus,
t11FLockRejectReasonCode,
t11FLockRejectReasonCodeExp,
t11FLockRejectReasonVendorCode,
t11FLockRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects containing information
about current Fabric locks."
::= { t11FLockMIBGroups 1 }
END
(next page on part 2)