• Class 1: A CoS providing a dedicated connection between two ports with confirmed delivery or notification of non-delivery
• Class 2: A CoS providing a frame switching service between two ports with confirmed delivery or notification of non-deliverability
• Class 3: A CoS providing a frame switching datagram service between two ports or a multicast service between a multicast originator and one or more multicast recipients
• Class 4: A CoS providing a fractional bandwidth virtual circuit between two ports with confirmed delivery or notification of non-deliverability.
Class 4 is often called a virtual circuit CoS. It works to provide better QoS guarantees for bandwidth and latency than Class 2 or Class 3, while providing more flexibility than Class 1. Similar to Class 1, it’s a type of dedicated connection service. Class 4 is a connection-oriented CoS with confirmation of delivery (acknowledgement) or notification that a frame couldn’t be processed (reject). Class 4 provides for allocating a fraction of the bandwidth on a path between two node ports and guarantees latency in negotiated QoS bounds. It provides a virtual circuit between a pair of node ports with guaranteed bandwidth and latency in addition to the confirmation of delivery or notification of non-deliverability of frames. For the duration of the Class 4 virtual circuit, all resources necessary to provide that bandwidth are reserved for that virtual circuit.
Unlike Class 1, which reserves the entire bandwidth of the path, Class 4 supports the allocation of a requested amount of bandwidth. The bandwidth in each direction is divided among up to 254 virtual circuit connections to other N_Ports on the fabric. When the virtual circuit(s) is established, resources are reserved for the subsequent delivery of Class 4 frames. Like Class 1, Class 4 provides in-order delivery of frames. A Class 4 circuit includes at least one virtual circuit in each direction with a set of QoS parameters for each virtual circuit. These QoS parameters include guaranteed transmission and reception bandwidths and/or guaranteed maximum latencies in each direction across the fabric. When the request is made to establish the virtual circuit, the request specifies the bandwidth requested and amount of latency or frame jitter acceptable.
The Quality of Service Facilitator (QoSF), a server in the fabric, manages bandwidth and latency guarantees for Class 4 virtual circuits. The QoSF is at the well-known address x’FF FFF9’ and is used to negotiate, manage and maintain the QoS for each virtual circuit and assure consistency among all the virtual circuits set up across the full fabric to all ports. The QoSF is an optional service defined by the Fibre Channel Standards to specifically support Class 4 service. Because the QoSF manages bandwidth through the fabric, it must be provided by a Class 4 capable switch/director.
At the time the virtual circuit is established, the route is chosen and a circuit created. All frames associated with the Class 4 virtual circuit will be routed via that circuit, ensuring in-order frame delivery in a Class 4 virtual circuit. In addition, because the route is fixed for the duration of the circuit, the delivery latency is deterministic. With Class 4, the virtual circuits can be in a dormant state with the virtual circuit set up at the N_Ports and through the fabric, but with no data flowing, or a live state where data is actively flowing. To set up a Class 4 virtual circuit, the Circuit Initiator (CTI) sends a Quality of Service Request (QoSR) extended link service command to the QoSF. The QoSF ensures the fabric has the available transmission resources to satisfy the requested QoS parameters and then forwards the request to the Circuit Recipient (CTR). If both the fabric and recipient can provide the requested QoS, the QoS request is accepted and the transmission can start in both directions. If the requested QoS parameters can’t be met, the request is rejected.
In Class 4, the fabric manages the flow of frames between node ports and the fabric by using the virtual circuit flow control mechanism. This is a buffer-to-buffer flow control mechanism similar to the R_RDY Fibre Channel flow control mechanism. Virtual-circuit flow control uses the Virtual Circuit Ready (VC_RDY) ordered set. VC_RDY resembles R_RDY, but it contains a virtual circuit identifier byte in the primitive signal, indicating which VC is being given the buffer-to- buffer credit. Managing the flow of frames on Inter-Switch Links (ISLs) also must support the virtual circuit flow control to manage the flow of Class 4 frames between switches.
Each VC-RDY indicates to the N _ Port that a single Class 4 frame is needed from the N_ Port if it wishes to maintain the requested bandwidth. Each VC_RDY also identifies which virtual circuit is given credit to send another frame. The fabric controls the bandwidth available to each virtual circuit by the frequency of VC_RDY transmission for that circuit. One VC_RDY per second is permission to send one frame per second (2 kilobytes/second if 2k frame payloads are being used). One thousand VC_RDYs per second is permission to send 1,000 frames per second (2MB per second if 2k frame payloads are being used). The fabric is expected to make any unused bandwidth available for other live Class 4 circuits, and for Class 2 or Class 3 frames, so the VC_RDY does allow other frames to be sent from the N_Port.
There are some potential scalability difficulties associated with Class 4 service, since the fabric must negotiate resource allocation across each of the 254 possible VCs on each N _Port. Also, fabric busy (F_BSY) isn’t allowed in Class 4. Resources for delivery of Class 4 frames are reserved when the virtual circuit is established, so the fabric must be able to deliver the frames.
Class 4 is a complex issue. More detailed information is available in Kembel’s The Fibre Channel Consultant series of textbooks. Because of its complexity, Class 4 was never fully adopted as a standard. Further work on it was stopped, and much of the language has been removed from the FC standard. For that reason, other mechanisms and models for QoS in FICON were examined. One of these was the method used by Infiniband.
Infiniband and QoS