3.6 Framing Protocol

To move data from one Fibre Channel-attached device to another, the data blocks handed down by the upper-layer protocol of the sender must be organized into discrete packets for shipment across the transport. In Fibre Channel nomenclature, data packets are referred to as frames.

Table 3-2. Fibre Channel Frame Format

SOF

Header

Data Field

CRC

EOF

As shown in Table 3-2, frames are always prefaced with an ordered set start of frame (SOF) delimiter. This is a single 4-byte word that defines the class of service used and specifies whether the frame is the first in a series or simply one in a series of related frames. Following the SOF, a 24-byte frame header contains destination and source addressing, as well as control fields that indicate the frame's content (control information or data type) and position within a series of sequential frames.

After the header, the data unit itself may be from 0 to 2,112 bytes. This variable-length data framing technique allows Fibre Channel to accommodate various application requirements with a reasonable balance between frame overhead and payload. Because Fibre Channel frame construction is based on multiples of 4-byte transmission words, the user data must be padded with additional fill bytes if the total byte count is not evenly divisible by 4. A 509-byte payload, for example, would need 3 additional fill bytes for proper frame alignment. Data integrity within the frame is verified with a 32-bit cyclic redundancy check (CRC). The CRC calculation is performed before the data is run through the 8b/10b encoder, and the 4-byte CRC itself is later encoded along with the rest of the frame contents. Following the CRC, an end of frame (EOF) ordered set is appended to notify the recipient that the frame is complete. The specific EOF used is determined by the class of service and whether the frame is one of or the last in of a series of frames.

In addition to the standard 24-byte frame header, optional headers can be used for applications that require extensive control fields. To keep the total frame size within 2,148 bytes, the optional headers must occupy part of the 2,112-byte data space, and this may reduce the data payload by as much as 64 bytes per frame. You should recognize the presence of optional headers when calculating data throughput in Fibre Channel environments. For most applications, it is sufficient to simply count the bytes between SOF and EOF and deduct 28 bytes (normal header + CRC) to determine the data payload.

After the frame is assembled, the frames are delivered via a protocol hierarchy of sequences and exchanges. A sequence can include one or more related frames for example, a block of data written to disk via multiple frames whereas an exchange can include one or more unrelated sequences. Two communicating devices, in turn, can have several exchanges established at the same time, with unique exchange IDs and sequence IDs separating the traffic. This nested structure of exchanges and sequences of frames maximizes utilization of the link between two devices, with minimal overhead for setting up and tearing down logical connections.

To further minimize overhead in frame transport, Fibre Channel limits error recovery to the sequence level. If a frame fails the CRC check, for example, it is more efficient to recover by reissuing the entire sequence of frames at gigabit speed than to embed the logic required to track and recover individual frames. Reliance on sequence-level recovery is also a testimony to the link integrity expected for the Fibre Channel transport. If an extremely low bit error rate is maintained by the Fibre Channel infrastructure, few sequence recoveries are required.



Designing Storage Area Networks(c) A Practical Reference for Implementing Fibre Channel and IP SANs
Designing Storage Area Networks: A Practical Reference for Implementing Fibre Channel and IP SANs (2nd Edition)
ISBN: 0321136500
EAN: 2147483647
Year: 2003
Pages: 171
Authors: Tom Clark

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net