1. FLIP Architecture & Requirements Roger Cummings Symantec roger_cummings@symantec.com

2. Introduction I-D draft-cummings-imss-flip-00 submitted 10/17 –Detailed background to FAIS & its object model –FLIP Architectural approach & potential relationship to NETCONF –Requirements 01 version submitted on 11/7 –Only adds object model figure

3. Fibre Channel Architecture defines Servers interconnected with storage devices via infrastructure abstraction called a “Fabric” –Fabric may be implemented by active interconnects (switches) or passive ones (loops) –Line speeds may be mixed in Fabric Today range from 1 to 4 GBit/s High level of commonality with GbE physical & encoding

4. FAIS C level API for use by applications resident in the fabric –Defines interface to an abstraction of a high- performance hardware frame processing engine (DPC) –Abstraction defined in terms of an object model with 19 classes Initially support 2 classic storage functions (Virtualization & RAID) –Extensible to others Transports SCSI command sets

5. FAIS Architecture

6. Detailed FAIS functions Perform all of the functions of one or more SCSI Targets Perform all of the functions of one or more SCSI Initiators Configure and control high-performance command/data forwarding and manipulation facilities present in the underlying equipment Delegate the processing of specific SCSI command types addressed to specific entities to those facilities

7. +-----------------------------+ | 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 | +-----------------------------+ Object Model Supports 3 types of volumes –Striped –Concatenated –Mirrored Plus XMap (address transformer) Plus multiple levels of hierarchy Also classes related to front and back end interfaces

8. FAIS Service Groups General Services –Used by multiple other services Port Services –Create, destroy and ops on SCSI Ports Front-End Services Back-End Services Volume Management Services –Mapping virtual volumes between front and back ends –Create Xmaps –Quiescing and Resuming block ranges

9. FLIP Architecture External Virtualization Application FLIP

10. Comm protocol between external application & receptor on Fabric switch –Receptor then acts as “thin” FAIS_Client Major advantages –App vendors don’t have to develop for each switch –Also app vendors don’t have to work out a deployment strategy –Switch vendors can ship a standard thin FAIS client with all switches

11. FLIP Requirements Support a VERY thin FAIS_Client/FLIP Receptor Add as few semantics to existing FAIS calls as possible and modify no existing semantics –1-1 mapping of FAIS functions calls to RPCs Optimize for case when read/write data is NOT transferred over FLIP Be transport-independent and allow app protocol to be any of a number of standard IETF protocols that support following reqs –Provide persistent connection-oriented semantics Connection must provide reliable, sequenced data delivery. –Provide authentication, data integrity, and optionally privacy

12. FLIP Layering 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. | +--------------+ +-----------------------------+ Defined by FAIS API Converts FAIS structures Maps FAIS semantics Discovery, establish handles Establish communications

13. NETCONF layering Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | |, | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | |, | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Application | | BEEP, SSH, SSL, SOAP | | Protocol | | | +-------------+ +-----------------------------+ Would work for FLIP Don’t think will support all FAIS service groups (e.g. object create/delete in hierarchies) Advantages for FAIS: Leverage existing RPC & below plus perhaps emerging datatypes Disadvantages for FAIS: Need new set of operations & discovery, timescale?

14. Issues FLIP has to transport bulk binary data in some situations –Don’t want to XML encode! –Separate connection using RDDP protocols? –Others?

15. T11.5 Status Presented the IETF-63 slides @ T11.5 in August –Have indications of interest from 3 people, including 1 who will volunteer as editor Have not posted the I-D to T11.5 – wanted to discuss this here first –FAIS is in Letter Ballot (equiv to WG Last call) in T11, closing 11/24

16. Going Forward Does NETCONF approach make sense –Tie in to other current IETF activities? Other things we can leverage? Should the focus of this work be imss or T11.5? –Even in the latter case could bring forward to imss @ later stage (same process as being followed for MIBs)