IP over Fibre Channel Working Group INTERNET-DRAFT 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