1 / 16

FLIP Architecture & Requirements

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

keenan
Télécharger la présentation

FLIP Architecture & Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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

  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. 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

  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 | | <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?

  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)

More Related