Draining the Virtualization Swamp

1
Draining the Virtualization Swamp

• T11/08-554v1
• 31 October 2008
• Bob Nixon (bob.nixon_at_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).

3
Architectural Model
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.

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.

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

7
Are we there yet?