IP over Fibre Channel Working Group
INTERNET-DRAFT
<draft-ietf-ipfc-mib-framework-00.txt>
                                                                        Lee C. Hu
                                                              Vixel Corporation
                                                                   Gavin Bowlby
                                                         Gadzoox Networks, Inc.
                                                                Mark A. Carlson
                                                               Sun Microsystems

                                                                    June 25, 1999


             A Framework for Fibre Channel MIBs


Status of this Memo

   This document is an Internet-Draft. This document is an Internet-
   Draft and is in full conformance with all provisions of Section 10
   of RFC2026.   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working groups.
   Note that other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).  Distribution of this memo is unlimited.

Abstract

   This document discusses technical issues and requirements for the
   management information base (MIB) for Fibre Channel and storage
   network applications.  This document is likely to be expanded to
   include management of specific Fibre Channel device types in the
   future. The purpose is to have an overall structure and view of
   Fibre Channel MIBs for consistency and interoperability. This
   document does not try to cover the details of each individual MIB.

   This is an initial draft document, which will evolve and expand
   over time. It is the intent of this document to produce a coherent
   description of a framework for various MIB development which were
   and are being considered by the working group.  Selection of
   specific approaches, making choices regarding engineering tradeoffs,
   and detailed protocol specification, are outside of the scope of
   this framework document.

 Expiration Date: Dec 25, 1999


   Note that this document is at an early stage, and that most of the
   detailed technical discussion is only in a rough form. Additional
   text will be provided over time from a number of sources.

Acknowledgments

   This is a group effort of IP over Fibre Channel.  Many of the ideas
   are from the discussions and various inputs from attendees of
   IPFC and some other industrial forums and standards groups.

Table of Contents

 1. Introduction
 2. Scope
 3. Principles
 4. Assumptions
 4.1 Security
 4.2 SNMP Version Compatibility
 4.3 Standardized MIB support
 4.4 Proprietary MIB support
 5. Structure:
 5.1 Definition/ Terminology
 5.2 Devices
 5.3 MIB Tree
 6. Appendices and References


1. Introduction
   Fibre Channel is an ANSI T11 standards based network designed
   particularly for connecting storage devices and servers/hosts at
   high-speed by using fiber optics.  A Fibre Channel topology is a
   group of networked Fibre Channel components which are used to
   communicate real-time and non-real-time data. The ever growing
   complexity of the Fibre Channel Interconnect and storage networks
   requires a consistent and interoperable management interface.  MIBs
   are the essential building block to realize such system management
   need. This framework is used to outline a MIB structure and serve as
   a guideline for users to find various MIBs and their relations in
   Fibre Channel applications.

   A Fibre Channel based storage area network can consist of switches,
   hubs, transceivers, host adapters, ports, storage devices, HBAs,
   and/or, physical parts like enclosures.  Fibre Channel components
   can be connected in configurations like point-to-point, loop, or a
   multiple-point-to-multiple-point network through switch or hub
   components. By interconnecting them, a local area network can be
   formed to support variety of real-time multimedia and data
   communication needs, particularly for storage access.


2. Scope
   This document can be used to provide a roadmap for Fibre Channel MIB
   development and a guide for users.  It covers Fibre Channel
   components, interconnection devices, and storage networking
   components.

   The document does not try to cover every foreseeable device in Fibre
   Channel storage network area.  Instead, it will outline a structure
   for future development and help users in their applications.  It is
   going to be an evolving process to revise the document as Fibre
   Channel standards and product deployments evolve.  Further, it is
   the intent to include Fibre Channel MIBs-based management in the
   future.


3. Principles

The following principles should be observed in developing MIBs.

Semantic content - enough information should be provided to program
against without knowing about the vendor and implementation.

Revision and revision compatibility - revision should be embedded in
MIBs so a processing entity can identify the MIB and process it
accordingly.  Backward compatibility is required.

Monitor/control - MIBs can be either readable or writable or both.

Local/remote - MIBs should be written such there is no difference for
Accessing locally or remotely, e.g. through a 10 km link, for
management purposes.

Management domains - dividing the scope of management. A management
domain can be used to partition a set of Fibre Channel devices (usually
from a single vendor) to allow vendor-specific mechanisms to be used to
manage the set of devices.

Fibre Channel debugging - exposing sufficient information to enable FRU
level fault isolation

Performance metrics - metrics should be exposed that allow performance
measurement and tuning of the storage data path.

Availability metrics - metrics should be exposed that allow the
measurement and monitoring of availability including uptime, operational
hours, and error counters.

Discovery/topology - sufficient connectivity information (link tables)
Should be exposed such that a management system can construct a
topological view of the storage network with all connected resources.

Structure - The MIBs should have a structure of generic part and
specific part for a device.  For example, group all generic information
of a Port into generic part and have specifics (e.g. an E_Port
characteristics) in the specific part.

The existence of MIBs does not rely on the functions of a Fibre Channel
interconnection topology. (persistent with or without the full
functions of a set of Fibre Channel Interconnection devices).


4. Assumptions

4.1 Security

This section describes some details of Fibre Channel device security
that are not directly related to actual MIBs, but to management of a
Fibre Channel device. These details are closely related to MIBs,
however, so they are included in this section.

For all MIBs covered under the IP over FC working group, the following
security provisions apply:

* A mode may be provided where all MIB objects are treated as read-only
objects, regardless of their definition in the MIB. This mode will
satisfy some of the security requirements of customers who feel that
SNMPv1 security measures are insufficient to guard against unauthorized
access.

This mode is still useful even with versions of SNMP other than SNMPv1
loaded into an agent, when a customer may want to disable all writes to
a set of MIB objects from an NMS. In this mode, customers may use a
serial console interface or a Telnet console to perform the equivalent
MIB Set functions.

An example of this may be a MIB object which can be set to a value to
cause a reset to occur on the addressed piece of equipment. If SNMP
Sets to this object are not allowed, the user could still perform the
reset operation through a serial console GUI or through a Telnet
console, assuming they had met any password challenges implemented in
these interfaces.

An implementation may choose to protect a subset of the writable MIB
objects in the above manner from write accesses. For example, a write
to a MIB object that performs a reset to a piece of equipment may not
be allowed, but a write to a MIB object that clears an error log may be
allowed. It's up to the security policies of each agent implementation
to determine which MIB objects may be written, and which MIB objects
can't be written.

For SNMP Sets to objects that are protected as described above, an SNMP
"generic error" response should be returned by the SNMP agent to the
originator of the SNMP Set request.

Control of this mode of operation will typically be implemented via a
serial console GUI, a Telnet console or other secure means.


* All MIB objects defined as read-only should be accessible from an NMS
via SNMP, provided that the applicable SNMP security mechanisms have
been passed to allow SNMP read access to the object.


* Other protocols may be implemented to control access of writable MIB
objects, or to provide additional control points than are defined in
the MIB.

An example would be a Web-based interface that was launched from
information available within a MIB. This interface could implement
additional objects, not specified within a MIB, that used HTTP-based
security mechanisms to authorize writes to these objects.

An implementation may choose to support writable MIB objects using HTTP
as the access mechanism for the writable MIB objects. In this case, the
MIB objects would not be accessible from SNMP, but would be accessible
through a Web-based interface.


4.2 SNMP Version Compatibility

Fibre Channel MIBs defined in the IP over FC working group should be
written in the SNMPv1 syntax.

As SNMPv3 becomes available, MIBs may be written in the SNMPv3 syntax
also. However, the baseline version of all FC MIBs should remain
SNMPv1. Every attempt should be made to keep the SNMPv1 and SNMPv3
versions of the MIBs as close as possible.


4.3 Standardized MIB support

The following standardized MIBs should be supported in all SNMP-
addressable Fibre Channel devices, for reasons of compatibility with
existing Network Management Software:

* MIB2, RFC 1213

Implementation of this MIB can be used to describe an out-of-band
Ethernet management port on a Fibre Channel device, or can be used to
allow generic management of the Fibre Channel device itself.


4.4 Proprietary MIB support

A vendor may choose to implement proprietary MIB extensions to the
standardized Fibre Channel MIBs to expose vendor-unique features to
Network Management Software and/or a user. Fibre Channel device vendors
may implement features that do not easily fit into the standardized
MIBs, and these features need to be exposed to vendor-specific GUIs for
management.


5. Structure

5.1 Definitions / Terminology

Cabinet
A physical enclosure host a number of Fibre Channel devices.

Connectivity Unit
This refers to any device that supports SNMP operations.

Device
A Fibre Channel device; this may consist of a Fibre Channel
Interconnect Element or a Fibre Channel Edge device.

Edge Device
A Fibre Channel device that does not provide Interconnection
capabilities to other devices. Examples of these devices are Host Bus
Adapters and Storage Devices.

Fabric
The entity which interconnects various N_Ports attached to it and is
capable of routing frames by using only the D_ID information in a FC-2
frame header.

HBA
A device that is used to build a Fibre Channel Arbitrated Loop
topology. This device may or may not be manageable, and may or may not
contain an embedded NL_Port.

Hub
A Interconnect Element that is used to build a Fibre Channel Arbitrated
Loop topology. This device may or may not be manageable, and may or may
not contain an embedded NL_Port.

In Band Management
With the advent of IP over Fibre Channel, the SNMP transport can also
use the same path as the data transfer, competing with the data for
the available bandwidth.

In-band protocol
A sequence of frames exchanged between a set of Fibre Channel ports that
is encoded by the FC-1 transmission protocol.

Interconnect Element
A device that can be used to connect a set of Fibre Channel ports to
each other. This may include Fabrics, Hubs, Switches, or Bridges.

Internetwork devices: BBW, BBL, and bridges
A device is used to connect a Fibre Channel topology and a general
network, e.g. Ethernet, ATM, or Sonet.

Loop Initialization Protocol
A protocol defined in FC-AL2 that allows a set of NL_Ports and FL_Ports
to acquire a set of AL_PAs that can be used to communicate with each
other.

Manageable Device
A Fibre Channel device that can be managed, either through a direct
out-of-band connection (e.g. Ethernet), through a Proxy Master (with
an in-band or out-of-band protocol), or through a direct in-band
protocol.

Manageable Hub
A hub that can managed, either by an in-band protocol or an out-of-band
protocol.

Manageable Hub with embedded NL_Port
A manageable Hub that contains a Fibre Channel NL_Port. This hub is
capable of supporting (Fibre Channel) in-band protocols.

NMS
Network Management System, along with the software in the station
that allows a user to manage a set of Fibre Channel devices.

Out-of-band Management
With Fibre Channel Networks, the SNMP transport can take place via
a different path than that used for data transfer. This is typically
done through a standard ethernet port.

Port
A generic reference to an N_Port, NL_Port, F_Port, FL_Port, or E_Port.

Proxy Index
An arbitrary index that is associated with a device within a Proxy
management domain. This index can be used to access various MIB
objects that represent a value on each proxied device.

Proxy Management Domain
A collection of devices (usually from a single vendor) that can be
managed through a proxy MIB from a proxy master device. A single
proxy master device can manage all of the devices contained within
a proxy management domain. This collection may consist of a single
manageable device.

Proxy Master
A device that can manage a set of devices (usually from a single
vendor) within a Proxy Management Domain. This device typically
has an Ethernet connector, and an IP address associated with it.
This device supports protocols (such as SNMP) between itself and
an NMS. Note that these protocols may be in-band or out-of-band
protocols. The set of devices that the Proxy Master manages may
be a single device (the Proxy Master itself).

RNID
Request Node ID ELS frame. This ELS request is used to discover
the device type of the addressed device.

RTIN
Return Topology Information ELS frame. This ELS request is used
to retrieve Fibre Channel Topology information from the addressed
Fibre Channel Interconnection Element.

Storage device
A storage device is used for data storage. It includes (but not limited
to) hard disk, CD, and tape.

Switch
1. A Fabric Element conforming to ANSI FC-SW Standard. 2. A member of
the Fabric collective.

Transceiver
A transmitter and receiver combined in one package.

Unmanageable Device
A Fibre Channel device that cannot be managed, either through
an in-band protocol or an out-of-band protocol.

Unmanageable Hub
A hub that cannot be managed, either through an in-band protocol
or an out-of-band protocol. This hub cannot be represented by an
NMS, since it can't be addressed by any mechanism.


5.2   Devices

This part gives a potential coverage of managed components.  It is not
intended to have a "MIB" document created for each of components listed
here.

   Physical devices
        switch
        hub:
          switching hub
          hub
        hba
        internetwork devices:
          Tunneling devices:
            BBW-ATM
            BBW-SONET
            BBL-FDDI
            ...
        storage devices
          disk
          tape
          CD
          ...
        ports
          N_Port
          E_Port
          Loop_info
        transceiver
        enclosure

   Groups of information:
   a) version
        type
        state
        configuration

   b) errors
        faults and diagnostics

   c) statistics/ performance
        utilities

   d) vendor specifics


5.3 MIB tree

Fibre Channel MIBs should be located under the "Fibre Channel" branch
of the "experimental" MIB, 1.3.6.1.3.42.

Current MIBs located in the Fibre Channel branch:

Fabric Element MIB: 1.3.6.1.3.42.2

These MIBs may consist of an arbitrary collection of groups, and may
contain objects of type: READ-ONLY, READ-WRITE, or WRITE-ONLY.

All objects that are not implemented by an agent should either return a
"no such instance" error when accessed, or should return a null value
for the object. Null values consist of 0 for INTEGER type objects, and
the Null string for OCTET STRING type objects.

These MIBs should provide for proxy SNMP management. In other words,
at a relatively high level of the MIB, table(s) should exist that allow
multiple entities to be referenced. The indexing of the table should
allow multiple entities to be referenced through a single SNMP agent,
at a single IP address.

In general, an agent will proxy for a group of devices from a single
vendor. The method which an NMS uses to determine a set of addressable
agents is beyond the scope of this document.

It's advisable that a MIB object exist within each FC MIB that contains
the version number of the particular FC MIB. This MIB object should be
at a fixed OID within the MIB, such that future versions of the MIB are
backward compatible with respect to the version number object. Backward
compatibility for this MIB object allows an NMS to support multiple
versions of a particular FC MIB.


6.  References

[1]  Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[4]  J.D. Case, C. Partridge, Case Diagrams: A First Step to Diagramed
     Management Information Bases.  Computer Communications Review,
     Volume 19, Number 1, (January, 1989).

[5]  K. McCloghrie and M. Rose, "Management Information Base for
     Network Management of TCP/IP-base Internet: MIB-II," RFC1213,
     March 1991.

[6]  G. Bowlby and M. E. O'Donnell, "Proposed Fibre Channel Physical
     Topology Discovery Procedure," SNIA, April 1999


Author's Email Addresses

     Lee C. Hu
     lhu@vixel.com

     Gavin Bowlby
     gavin@gadzoox.com

     Mark A. Carlson
     mark.carlson@sun.com



































Expiration Date: Dec 25, 1999