1 / 7

Draining the Virtualization Swamp

Draining the Virtualization Swamp. T11/08-554v1 31 October 2008 Bob Nixon ( bob.nixon@emulex.com ). Draining the Virtualization Swamp.

lucio
Download Presentation

Draining the Virtualization Swamp

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. Draining the Virtualization Swamp T11/08-554v1 31 October 2008 Bob Nixon (bob.nixon@emulex.com)

  2. Draining the Virtualization Swamp • The prior version of this presentation (T11/08-544v0) gave a tutorial introduction to resolving some remaining issues with the FC virtualization architectural model • This version omits the tutorial and includes changes recommended by those who reviewed the first version. • It also attempts to resolve two issues that remained incomplete after the last meeting week: • node container Platform - FC-GS-x for a system-level entity that acts as an endpoint for Fibre Channel communication. • “Platform devices include end devices attached to the Fabric through a Fibre Channel Node and its associated Ports. Examples of platform devices are host systems and storage subsystems. Fibre Channel Nodes and their associated Ports are contained within a platform device.” • Add a Multiplexer, that performs the FC-2M function (requested by FC-SW-5). T11/08-554v1

  3. Architectural Model T11/08-554v1

  4. New/revised terminology • FC-2 Multiplexer sublevel: The sublevel in the Fibre Channel architecture that routes frames between FC-2V instances (e.g., VN_Ports) and one or more LCFs, based on the D_ID in the Frame_Header (see 9.5) and the VF_ID in the VFT_Header if there is a VFT_Header (see 10.2.4). • FC_Port: A port that is capable of transmitting and receiving Fibre Channel frames according to the FC-0, FC-1, FC-2P, FC-2M and FC-2V levels of the Fibre Channel architecture. An FC_Port contains at least one LCF and at least one VN_Port, and may contain other types of FC-2V instances (e.g., an F_Port Controller) (see FC-SW-5). Note: This standard does not specify the operation of more than one LCF in a single FC_Port. • Multiplexer: An entity that provides the functions of the FC-2M sublevel. • node: A collection of one or more VN_Ports controlled by a level above FC-2. Frames received at a node are not forwarded to another node. • Platform: A container for one or more nodes and one or more LCFs. Frames received at a Platform are not forwarded to another Platform. Any additional characteristics of a Platform are outside the scope of this standard. • PN_Port: An LCF in a Platform. • VFT Tagging PN_Port: A PN_Port operating with a Multiplexer that has enabled processing of Virtual Fabric Tagging Headers. • vnode: Synonymous with node. The term vnode is used when it is desired to emphasize support for multiple nodes in a single Platform. T11/08-554v1

  5. Architectural text • The architectural components associated with a Fibre Channel node are: • a Platform, that contains one or more vnodes; • one or more vnodes, each of which identifies a collection of one or more ULPs and their FC-4 mappings, an FC-3 level, and one or more VN_Ports; • one or more ULPs, which are application protocols carried over Fibre Channel; • an FC-4 mapping for each ULP onto the FC-3 functions offered by the vnode and the FC-2 functions offered by each VN_Port; • one or more VN_Ports, each of which is an independent end point for Fibre Channel communication; • one or more Multiplexers, each of which routes frames between a set of VN_Ports and a set of PN_Ports; and • one or more PN_Ports, each of which is an LCF that operates a Fibre Channel link. • The architectural model of a Switch may be found in FC-SW-5. T11/08-554v1

  6. Impact: much less than I expected • Glossary updates where needed • Change node to Platform • 59 in FC-FS-3, (mostly in Clock Synch, e.g., “node delay”. Is this really necessary?) • about 10 in FC-LS-2 (in RSCN and RNID) • Hand-wave for ENode in FC-BB-5. It’s not too badly misaligned. • 1 in FC-SW-5 • Several in FC-SB-4, or, require one vnode to one platform • FC-GS-6 is a future hook on which I am already caught • Change PN_Port or its context • In FC-FS-3: ~40, most concerning VF capable PN_Ports • in FC-LS-2 (actually, 08-379v1): ~40 mostly for VF capable PN_Ports T11/08-554v1

  7. Are we there yet? T11/08-554v1

More Related