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