|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Towards a more effective PDU formatAll: Here is a proposal for an iSCSI PDU format without WN Next-Qualifiers: 1. Every PDU must start with a 48-byte Basic Header Segment (BHS). Assuming header digests are in use, this BHS is immediately followed by a header digest that covers it. 2. Every BHS contains 2 fields at fixed locations: a) AHS-length, containing the total length of all Additional Header Segments (AHS) that follow. This field is 0 if there are no AHSs. b) DATA-length, containing the total length of all Data that follows the AHSs. This field is 0 if there is no data. 3. If the AHS-length field in the BHS is non-zero, all the AHSs immediately follow the header digest of the BHS. An additional digest immediately follows that last AHS and covers all the AHSs. 4. If the DATA-length field in the BHS is non-zero, all the data immediately follows the AHS digest. A data digest immediately follows the data. 5. If space within the BHS is an issue, the AHS-length field could be restricted to a single byte, and could be in units of 4-byte words. This would allow up to 1020 bytes of AHSs to follow a BHS, and this seems to be more than enough for the uses foreseen (so far, only extended CDB and bidi-read info). 6. Each AHS should start with a word containing a TYPE field and a LENGTH field. The TYPE field should be enumerated rather than bit-field encoded, for easier decoding and future expansion. The LENGTH field is the number of bytes of additional information in this AHS that follows this word. Advantages of this proposal. 1. The receiver always knows where to find digests in a reliable manner, without having to use unreliable data to find them. 2. Because the BHS is fixed length, the receiver can reliably obtain the entire BHS and its header digest in a single "read" operation. 3. Because the receiver gets the AHS-length field from the BHS, it can reliably obtain the entire set of AHSs and the header digest covering them in a single "read" operation. 4. Because the receiver gets the DATA-length field from the BHS, it can reliably obtain all the data and the data digest covering it in a single "read" operation. 5. Since each AHS begins with a word containing the TYPE and LENGTH in fixed positions, an unknown TYPE (i.e., a type introduced in the future that is received by a legacy receiver) does NOT result in loss of synchronization during header processing -- the receiver knows the length of this AHS in any case, and can just skip over it. Disadvantages of this proposal. 1. A second header digest is required, but only if one or more AHSs are present. In practice this should be a rare event. Proposed iSCSI PDU Format +-------------+ | 48-byte BHS | +-------------+ | BHS digest | --+-------------+-- | AHS 1 |\ | - - - - - - | \ | AHS 2 | \ | - - - - - - | > total length in AHS_length field in BHS | . . . | / | - - - - - - | / | AHS n |/ +-------------+ | AHSs digest | --+-------------+-- | |\ | Data | > total length in DATA_length field in BHS | |/ +-------------+ | Data digest | +-------------+ Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774
Home Last updated: Tue Sep 04 01:05:21 2001 6315 messages in chronological order |