Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4936

Fibre Channel Zone Server MIB

Pages: 84
Proposed Standard
Part 1 of 3 – Pages 1 to 23
None   None   Next

Top   ToC   RFC4936 - Page 1
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.
Top   ToC   RFC4936 - Page 2

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
Top   ToC   RFC4936 - Page 3

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
Top   ToC   RFC4936 - Page 4
   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:
Top   ToC   RFC4936 - Page 5
      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;
Top   ToC   RFC4936 - Page 6
   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.
Top   ToC   RFC4936 - Page 7
   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].
Top   ToC   RFC4936 - Page 8

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
Top   ToC   RFC4936 - Page 9
   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.
Top   ToC   RFC4936 - Page 10

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.
Top   ToC   RFC4936 - Page 11

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.
Top   ToC   RFC4936 - Page 12

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):
Top   ToC   RFC4936 - Page 13
   - 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
Top   ToC   RFC4936 - Page 14
                  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 }
Top   ToC   RFC4936 - Page 15
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
Top   ToC   RFC4936 - Page 16
           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
Top   ToC   RFC4936 - Page 17
           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
Top   ToC   RFC4936 - Page 18
           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.
Top   ToC   RFC4936 - Page 19
               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
Top   ToC   RFC4936 - Page 20
           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.
Top   ToC   RFC4936 - Page 21
              '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
Top   ToC   RFC4936 - Page 22
    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 }
Top   ToC   RFC4936 - Page 23
    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)

Next Section