IMSS Working Group Roger Cummings Internet Draft Symantec Corporation Expires: February 2006 October 14, 2005 FAIS Line Interface Protocol Architecture & Requirements draft-cummings-imss-flip-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire in February 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract FAIS Line Interface Protocol (FLIP) describes mechanisms that allow a set of functions that have been defined for an internal API related to storage virtualization to be extended to operate over a TCP/IP infrastructure. Significant deployment and configuration flexibility is gained by taking such an approach. Cummings Expires February 2005 [Page 1] Internet-Draft FLIP Architecture & Requirements October 2005 Conventions used in this document 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. FAIS Background and Architecture...............................4 2.1. Introduction..............................................4 2.2. Approach and Structure....................................4 2.3. Object Model Overview.....................................4 2.4. Attributes and Methods....................................5 2.5. Service Groups............................................5 3. FLIP Architecture..............................................5 4. FLIP Requirements..............................................6 5. Relationship to Other IETF Activities..........................7 6. Security Considerations........................................7 7. For further work...............................................7 8. Revision History...............................................8 9. References.....................................................8 9.1. Normative References......................................8 9.2. Informative References....................................8 Author's Addresses................................................8 Intellectual Property Statement...................................9 Disclaimer of Validity............................................9 Copyright Statement...............................................9 Acknowledgment....................................................9 NOTE: This is an initial document on a new subject for consideration by the IETF imss WG. Much refinement and further change is to be expected. Cummings Expires December 2005 [Page 2] Internet-Draft FLIP Architecture & Requirements October 2005 1. Introduction The Fabric Application Interface Standard (FAIS) is a project within Task Group T11.5 of the International Committee for Information Technology Standardization (INCITS) Technical Committee T11. T11 and the IETF imss WG already have active liaisons in place, and are cooperating on the definitions of MIBs related to storage networking. FAIS has attracted much attention as the first industry standard API that supports storage applications executing within equipment that forms part of a storage network infrastructure, (often known as a Storage Area Network), rather than within a server of client platform. FAIS supports both Switch-based and Appliance-based implementations. However feedback has already been received that the current configurations supported by FAIS do not address all of the industry's requirements. However those additional configurations involve addressing situations where information is exchanged over a TCP/IP infrastructure rather than a local API, and those situations are outside of the scope of work of T11.5. As a result of the above, an initial proposal was made to the IETF imss WG during IETF-63, and one week later at a T11.5 meeting in Ottawa, to consider extending the current liaison between the two groups to cover cooperation in this area. The proposal was well received in both groups, and this Internet-Draft is an initial attempt to scope the work that will be required, and derive an initial set of requirements. Cummings Expires February 2005 [Page 3] Internet-Draft FLIP Architecture & Requirements October 2005 2. FAIS Background and Architecture 2.1. Introduction [FAIS] is being developed under INCITS Project 1640-D, and has been in development in T11.5 since June 2003. That development work has now reached the stage that technical feature cutoff has been achieved and a draft is about to be formally balloted by the parent T11 committee. However one or more additional projects in this area are expected to be approved early in 2006 to continue technical development in the area. 2.2. Approach and Structure The beginning of the development of Storage Area Networks (SANs) can be traced back to the work on the Fibre Channel (FC) standards that began in T11 in 1988. 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 switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. FAIS is defined to support applications resident on an switch within a Fabric. FAIS is initially intended to support storage applications that perform one or two classic enterprise-level storage transformation processes, namely virtualization and RAID. Virtualization is an abstraction process by which the boundaries of the physical storage devices are hidden from operating systems and applications such as databases (e.g. eight 80 gigabyte disks may appear to the application as a single 640 gigabyte "virtual" disk. RAID (Redundant Arrays of Independent Disks) is a process that uses a set of physical storage devices to hold redundancy information as well as application data so that the failure of a physical storage device will not result in any application data loss. Cummings Expires February 2005 [Page 4] Internet-Draft FLIP Architecture & Requirements October 2005 FAIS does not itself define the protocol (command set) used to control the storage devices, but instead leverages the SCSI command sets define by a committee that is closely-related to T11, namely INCITS Technical Committee T10. The SCSI command sets have been in use for more than 20 years, and are transported over a number of existing storage interfaces, including Fibre Channel, SAS, Serial ATA and USB. A storage application may employ FAIS to: a) perform all of the functions of one or more SCSI Targets (see [SAM-3]), b) perform all of the functions of one or more SCSI Initiators (see [SAM-3]), c) configure and control high-performance command/data forwarding and manipulation facilities present in the underlying equipment, and d) delegate the processing of specific SCSI command types addressed to specific entities to those facilities. FAIS is defined as a a set of programming interfaces and data structures in the C Language that abstract the details of the implementation of the platform from the storage management application. The API is defined as providing for communication between a Client and a Provider. This approach is appropriate because API Client and Provider are defined as executing within the same environment in the same equipment. The FAIS_Client is the portion of a storage application that communicates with the FAIS_Provider using the FAIS API. The storage application is expected to perform such "classic" storage functions as virtualization and RAID. The FAIS_Client functionality includes initialization, data path configuration, exception handling, management operations and the maintenance of other state information. The FAIS_Client is responsible for building structures and mappings that reflect the intended data layout (abstraction) and accessibility. Additionally, the FAIS_CLient may perform data movement applications (e.g., snapshot copy, on-line migration, remote mirroring, asynchronous replication). The FAIS_Provider is an instance of the functionality within the equipment that provides the FAIS API to a FAIS_Client. The FAIS_Provider translates information received from the FAIS_Client into an appropriate form for use by a Data Path Controller (DPC) and vice versa. The DPC may be characterized as a high performance complex that operates on low-level units of interface information at line speed. Specifically in the case of FAIS those units are Frames defined by Fibre Channel. Those frame may contain SCSI commands and status as well as data. The DPC is programmed or "controlled" by the FAIS_client. Once the initial configuration is programmed, the DPC may process I/Os without intervention from the FAIS_Client. The DPC is dedicated to frame processing and does not, generally, process other instruction sets. The primary functions supported by the DPC are dynamic re-mapping of logical block addresses on SCSI disks and SCSI I/O faulting. Optionally, the DPC may provide other functions such as I/O duplication (mirroring) and I/O striping. 2.3. Object Model Overview FAIS abstracts the DPC and the ports of the switch on which it is resident by an Object Model containing 19 classes. A simplified view of the object model is shown below. (TBD) Cummings Expires February 2005 [Page 5] Internet-Draft FLIP Architecture & Requirements October 2005 The model contains: a) 4 classes related to "front-end" interface constructs i.e. associated with the SCSI Target function that communicates with a server; b) 6 classes related to "back-end" interface constructs i.e. associated with the SCSI Initiator function that communicates with one or more storage peripherals; c) 7 classes related to the definition of virtual storage Volumes with specific characteristics (e.g. mirrored, striped volumes) d) 2 classes related to an XMap, which is a specialized form of Volume that represents no storage but merely performs address transformations. Class relationships are explicitly modeled using standard object- modeling semantics. 2.4. Attributes and Methods Each of the objects described above has a defined set of Attributes and meta-atrtributes. FAIS defines three standard identifiers that are used with multiple classes, and a number of common data structures. Each of the objects defined above also has a defined set of methods. FAIS defines four separate opaque handles that are used with those methods. The methods typically support the creation, destruction, configuration and control of an instance of the class. 2.5. Service Groups The functions of the FAIS API are organized into the following major service groups: a) General Services including those types, data structures, or functions that may be used by more than one other defined service. b) Port Services that provide support for creating, destroying and performing operations on SCSI Ports. c) Front-end Services that provide support for processing requests and events that arrive at the FAIS_Client from the front-end. d) Back-end Services that provide support for discovering elements connected to the logical back-end of the platform, for receiving events related to the objects, and for issuing commands to devices on the back-end. e) Volume Management Services that provide support for building a mapping between virtual volumes presented to storage consumers on the front-end of the platform and storage provided by devices on the back-end. Also provides support for managing creation and updates of Xmaps as well as quiescing and resuming ranges of virtual volumes which have an Xmap type. 3. FLIP Architecture FLIP is conceived as a communication protocol between a storage application executing on a arbitrary platform, and a receptor executing on SAN switch. The receptor will then act internally as a FAIS_Client as described above. The concept is to make the receptor as simple and as "thin" as possible, and to add to the semantics supported by FAIS only those necessary to support the lower layers over which FLIP is being transported. The major advantage gained from the definition of FLIP is that it obviates the need for a storage application manufacturer to have to develop their own FAIS_Client for each brand of SAN switch, and then to find ways of having that client installed on switches in the field. FLIP allows virtualization applications to leverage FAIS without having to be installed on each switch, and also allows switch manufacturers to ship a single simple standardized FAIS client with all of their products. Cummings Expires February 2005 [Page 6] Internet-Draft FLIP Architecture & Requirements October 2005 FLIP is conceptually partitioned into five layers: Layer Example +--------------+ +-----------------------------+ (5) |FAIS Functions| | Create, delete etc. | +--------------+ +-----------------------------+ | | +--------------+ +-----------------------------+ (4) | Encoding | | XML or equivalent | +--------------+ +-----------------------------+ | | +--------------+ +-----------------------------+ (3) | RPC | | Function Call Semantics | +--------------+ +-----------------------------+ | | +--------------+ +-----------------------------+ (2) | Session/Con | | Connection & Session Est | +--------------+ +-----------------------------+ | | +--------------+ +-----------------------------+ (1) | App Protocol | | Secure, Authenticated, etc. | +--------------+ +-----------------------------+ Details of the layers are as follows: 1) The Application Protocol provides a communication path between the storage application and the receptor. 2) The Session/Connection layer deals with the discovery of entities capable of communication and the establishment of connections and sessions with appropriate configuration parameters. 3) The RPC layer maps the semantics of a FAIS function call to a remote procedure call. The initial approach will be to provide a 1-1 mapping. 4) The encoding layer provides an encoding/decoding function that converts the structures defined by FAIS to blocks of information suitable for encapsulation within a remote procedure call. 5) The FAIS functions are as defined by [FAIS]. 4. FLIP Requirements The requirements for FLIP are: 1) Support a VERY thin FAIS_Client/FLIP Receptor; 2) Add as few semantics to existing FAIS calls as possible and modify no existing semantics; 3) Optimize for the case when read/write data is NOT transferred over FLIP; 4) Be transport-independent and allow the application protocol referenced above to be any of a number of standard IETF protocols that support the requirements below. Requirements for an Application Protocol to support FLIP are: 1) Provide persistent connection-oriented semantics. The connection must provide reliable, sequenced data delivery. 2) Provide authentication, data integrity, and optionally privacy. Cummings Expires February 2005 [Page 7] Internet-Draft FLIP Architecture & Requirements October 2005 5. Relationship to Other IETF Activities [NETCONF] defines NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server. The client can be a script or application typically running as part of a network manager. The server is typically a network device. The terms "device" and "server" are used interchangeably in this document, as are "client" and "application". A NETCONF session is the logical connection between a network configuration application and a network device. NETCONF supports one or more sessions, and defines both global configuration attributes and Session-specific attributes. NETCONF is conceptually partitioned into four layers: Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Application | | BEEP, SSH, SSL, SOAP | | Protocol | | | +-------------+ +-----------------------------+ Details of the layers are as follows: 1) The application protocol layer provides a communication path between the client and server. NETCONF can be layered over any application protocol that provides a set of basic requirements. 2) The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. 3) The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. 4) The content layer is not currently well defined, and only limited efforts to specify a standard data definition language and standard content have yet started. Layers (1) and (2) are certainly applicable to FAIS, but the operations defined in layer 3 are certainly not extensive enough to support the semantics defined in section 2. It would therefore be necessary to define a new set of operations specifically to support FAIS, and it is not clear from the current NETCONF approach if this type of usage is being considered. For instance, there seems to be no current method by which the specific operations supported by a device can be discovered and enumerated. The advantages of adopting NETCONF Layers (1) and (2) for FLIP are the reuse of the RPC layer and the ability to leverage the existing application protocol definitions. Some of the emerging work on datatype definitions may also be able to be adopted. The disadvantages of adopting NETCONF Layers (1) and (2) for FLIP are the need to define a new set of options, the lack of discovery support and the somewhat uncertain timescale of ongoing NETCONF developments. 6. Security Considerations TBD 7. For further Work A major unknown at this time is the method of providing efficient and transparent data delivery through the encoding scheme defined for FLIP. Although FLIP will be optimized for the case where only SCSI commands and status, and configuration and control information are transported over FLIP, situations have to be supported where all of the data associated with SCSI read or write commands have to be transported over FLIP as well. Cummings Expires February 2005 [Page 8] Internet-Draft FLIP Architecture & Requirements October 2005 8. Revision History -00: Initial Version 8. References 8.1. Normative References [FAIS] T11/1620-D, Fabric Application Interface Standard ( http://www.t11.org/t11/docreg.nsf/ ldl/fais). [NETCONF] Enns, R. et al, "Internet draft (work in progress), draft-ietf-netconf-prot-09.txt, October 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SAM-3] INCITS 402-2005, SCSI-3 Architecture Model - 3. [SBC-2] INCITS 405-2005, SCSI-3 Block Commands - 2. [SPC-3] T10/1416-D, SCSI Primary Commands - 3. 8.2. Informative References ...TBD Author's Addresses Roger Cummings Symantec 1001 Heathrow Park Lane Heathrow, FL 32746 Phone: +1 407.357.7257 Email: roger_cummings@symantec.com Cummings Expires December 2005 [Page 9] Internet-Draft FLIP Architecture & Requirements October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). Internet-Draft FLIP Architecture & Requirements October 2005 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cummings Expires December 2005 [Page 10]