SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Towards a more effective PDU format



    All:
    
    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