Embed Size (px)
Citation preview
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
FAIS Architecture
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
+-----------------------------+ | 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
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 ArchitectureExternal 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 | | | +-------------+ +-----------------------------+
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?
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)
