One document matched: draft-ietf-ipfc-mib-framework-02.txt

Differences from draft-ietf-ipfc-mib-framework-01.txt

IP over Fibre Channel Working Group
INTERNET-DRAFT
<draft-ietf-ipfc-mib-framework-02.txt>

                                                             Mark A. Carlson
                                                             Sun Microsystems, Inc.
                                                             Gavin Bowlby
                                                             Gadzoox Networks,Inc.
                                                             Lee Hu
                                                             TWP Networks

                                                             March 10, 2000


             A Framework for Fibre Channel MIBs

Status of this Memo

   This document is an Internet-Draft. It 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.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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 was
   and is 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: September 10, 2000

   This document is in its final revision having been reviewed and
   approved by the IP over Fibre Channel working group. The intention
   is to move this to Informational RFC status at the next IETF.

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. Fibre Channel MIB Design Considerations
 4.1 General
 4.2 Security
 4.3 SNMP Version Compatibility
 4.4 Standardized MIB support
 4.5 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 to
   Fibre Channel applications.

   A Fibre Channel based storage area network can consist of switches,
   hubs, transceivers, host adapters, ports, storage devices, HBAs,
   and 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 a variety of real-time multimedia and data
   communication needs, particularly for storage access. This network
   is commonly referred to as a Storage Area Network, or SAN.



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.

   This document does not try to cover every foreseeable device in the 
   Fibre Channel storage network area.  Instead, it will outline a 
   structure for future development and help users in their applications.  
   This document will be updated as Fibre Channel standards and product 
   deployments evolve.  

3. Principles

The Fibre Channel MIBs may consist of an arbitrary collection of groups,
and may contain objects of type: READ-ONLY, READ-WRITE, or WRITE-ONLY.
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. MIBs
should conform to section 7.5 of RFC 2578 in this respect.

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 for all MIBs as
defined in Section 10 of RFC 2578.

Monitor/control - MIB objects can be either readable, writable or both.

Local/remote - MIBs should be written such there is no difference for
accessing objects 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). For example,
topologies such as a single pair of directly connected devices can still be
managed by a MIB.


4. Fibre Channel MIB Design Considerations

4.1 General

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.

4.2 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.

Conformance statements for a MIB should not require the implementation 
of write access, although vendors are encouraged to provide full control 
of their device through a remote protocol. For MIB objects that are only 
writable, conformance does not require implementation of the object.

For SNMPv3, the view based access control can also be used with SNMPv1
and should be specified in MIBs. 

Control of this mode of operation will typically be implemented via a
serial console GUI, a Telnet console or other secure means. The protocol 
definition for the appropriate version describes the behaviour for write 
attempts to an object which is not writable.

* 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.3 SNMP Version Compatibility

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

MIBs are required to be backward compatible as specified in RFC 2578.

4.4 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.5 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 hosting 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 under development should be located under the 
"Fibre Channel" branch of 1.3.6.1.3.42.2 until assingment by IANA.

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.

[7]  K. McCloghrie, D. Perkins, and J. Schoenwaelder, "Structure of 
     Management Information Version 2 (SMIv2)", RFC 2578, April 1999.


Author's Email Addresses


     Mark A. Carlson
     mark.carlson@sun.com

     Gavin Bowlby
     gavin@gadzoox.com

     Lee Hu
     lhu3@yahoo.com

Expiration Date: September 10, 2000