Internet DRAFT - draft-cummings-imss-flip
draft-cummings-imss-flip
IMSS Working Group Roger Cummings
Internet Draft Symantec Corporation
Expires: September 2006 March 3, 2006
FAIS Line Interface Protocol Architecture & Requirements
draft-cummings-imss-flip-02.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 September 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). 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 September 2006 [Page 1]
Internet-Draft FLIP Architecture & Requirements March 2006
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...............................3
2.1. Introduction..............................................3
2.2. Approach and Structure....................................4
2.3. Object Model Overview.....................................6
2.4. Attributes and Methods....................................7
2.5. Service Groups............................................7
2.6 Event Notifications.......................................8
3. FLIP Architecture..............................................8
4. FLIP Requirements.............................................10
5. Relationship to Other IETF Activities.........................10
6. Security Considerations.......................................12
7. For further work..............................................12
8. Revision History..............................................12
9. References....................................................13
9.1. Normative References.....................................13
9.2. Informative References...................................13
Author's Addresses...............................................13
Intellectual Property Statement..................................14
Disclaimer of Validity...........................................14
Copyright Statement..............................................14
Acknowledgment...................................................14
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 September 2006 [Page 2]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
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 has been formally balloted by the parent T11 committee.
Resolution of comments from that ballot is proceeding, and is
expected to completed in June 2006. However one or more additional
projects in this area are expected to be approved in the next few
months to continue technical development in the area.
Cummings Expires September 2006 [Page 3]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
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.
Cummings Expires September 2006 [Page 4]
Internet-Draft FLIP Architecture & Requirements March 2006
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
Cummings Expires September 2006 [Page 5]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
+-----------------------------+
| Front-End Interface Classes |
+--------------+--------------+
|
|
+-------v-------+
+------------------> <------------------+
| | VDev | |
|+-----------------> <-----------------+|
|| +-A--A--A--A--A-+ ||
|| | | | | | ||
|| +---------+ | | | +---------+ ||
|| | | | | | ||
|| +-------+-------+ | | | +-------+-------+ ||
|| | Striped VDev | | | | | Concat VDev | ||
|| +-------A-------+ | | | +-------A-------+ ||
|| | | | | | ||
|| +-------+-------+ | | | +-------+-------+ ||
|| | Column | | | | | Block Range | ||
|| +---------------+ | | | +-------+-------+ ||
|| | | | | | ||
|+---------+ | | | +---------+|
| | | | |
| +------------+ | +-------+ |
| | | | |
| +-------+-------+ | +-------+-------+ |
| | Mirrored VDev | | | XMap | |
| +-------A-------+ | +-------A-------+ |
| | | | |
| +-------+-------+ | +-------+-------+ |
| | Mirror | | | XMap Entry | |
| +-------+-------+ | +-------+-------+ |
| | | | |
+----------+ | +----------+
|
|
+--------------+--------------+
| Back-End Interface Classes |
+-----------------------------+
Cummings Expires September 2006 [Page 6]
Internet-Draft FLIP Architecture & Requirements March 2006
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 abstract (implementation-independent)
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-attributes. 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 a 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.
Cummings Expires September 2006 [Page 7]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
2.6. Event Notifications
The FAIS API described by the latest T11 document supports functions
that are synchronous or asynchronous, but not both. API functions
either present a synchronous or an asynchronous request method. For
asynchronous requests, the API schedules the request to be performed
and returns the status. A subsequent callback indicating the
completion status is generated after the request is complete.
FAIS does not currently support a model in which the FAIS_Provider
requests a service from or delivers an event
to the FAIS_Client. This would an asynchronous, unsolicited event and
the FAIS_Client would register to receive
these events by supplying a callback method for the each category of
events using methods provided by a new Service Group. However text in
the current document indicated that such a model will be addressed in
the next FAIS generation.
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.
Cummings Expires September 2006 [Page 8]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
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.
Cummings Expires September 2006 [Page 9]
Internet-Draft FLIP Architecture & Requirements March 2006
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.
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.
Cummings Expires September 2006 [Page 10]
Internet-Draft FLIP Architecture & Requirements March 2006
NETCONF is conceptually partitioned into four layers:
Layer Example
+-------------+ +-----------------------------+
(4) | Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(3) | Operations | | <get-config>, <edit-config> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(2) | RPC | | <rpc>, <rpc-reply> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(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.
Cummings Expires September 2006 [Page 11]
Internet-Draft FLIP Architecture & Requirements March 2006
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 operations, the lack of discovery
support and the complexity of co-ordination with 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.
8. Revision History
-00: Initial Version
-01: Added Object Model Diagram
-02 Updated info about T11 FAIS project, added details of data
structures & calls, anticipated notifications
Cummings Expires September 2006 [Page 12]
Internet-Draft FLIP Architecture & Requirements March 2006
9. References
9.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-11.txt, February 2006.
[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.
9.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 September 2006 [Page 13]
Internet-Draft FLIP Architecture & Requirements March 2006
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 (2006).
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 March 2006 [Page 14]
