160 likes | 304 Views
FLIP Architecture & Requirements. Roger Cummings Symantec roger_cummings@symantec.com. 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
E N D
FLIP Architecture & Requirements Roger Cummings Symantec roger_cummings@symantec.com
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
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
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
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
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 +-----------------------------+ | 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
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
FLIP Architecture External Virtualization Application FLIP
FLIP • 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
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
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
NETCONF layering Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | <get-config>, <edit-config> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | <rpc>, <rpc-reply> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Application | | BEEP, SSH, SSL, SOAP | | Protocol | | | +-------------+ +-----------------------------+ Don’t think will support all FAIS service groups (e.g. object create/delete in hierarchies) Would work for FLIP Advantages for FAIS: Leverage existing RPC & below plus perhaps emerging datatypes Disadvantages for FAIS: Need new set of operations & discovery, timescale?
Issues • FLIP has to transport bulk binary data in some situations • Don’t want to XML encode! • Separate connection using RDDP protocols? • Others?
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
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)