tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4936

Proposed STD
Pages: 84
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IMSS

Fibre Channel Zone Server MIB

Part 1 of 3, p. 1 to 23
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part