SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Reserved field definitions



    Robert,
    
    I iSCSI the reserved fiels are generally said to be 0 except in the very
    few cases in which we use a "reserved value" to indicate that the field has
    an invalid value and the value 0 is a (convenient) valid value. The tags
    fall in this category - Initiators may use for tags
    some simple derivative of a control-block-address and so do targets and
    reserving 0 was felt to be prohibitive.
    
    As for checking the reserved fields for the reserved value the draft
    refrains from asking this.
    
    As for some specifics - coments are inserted in text.
    
    Julo
    
    "Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 08-08-2001
    21:34:55
    
    Please respond to "Robert Griswold" <rgriswold@Crossroads.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   <ips@ece.cmu.edu>
    Subject:  Reserved field definitions
    
    
    
    Julian:
    
    In review the use of Reserved fields in the iSCSI draft, there seem to
    be some inconsistencies through the document, and the assumptions of
    their use appear to be in conflict with SAM-2.  First, two quotes from
    07 and SAM-2:
    
    "2. iSCSI PDU Formats
    ...  Any bits not defined MUST be set to zero. Any reserved fields and
    values MUST be 0 unless specified otherwise. "
    
    "3.3.8 reserved: A keyword referring to bits, bytes, words, fields and
    code values that are set aside for future standardization. Their use and
    interpretation may be specified by future extensions to this or other
    standards. A reserved bit, byte, word or field shall be set to zero, or
    in accordance with a future extension to this standard. Recipients are
    not required to check reserved bits, bytes, words or fields for zero
    values.  Receipt of reserved code values in defined fields shall be
    reported as an error."
    
    It appears that there are some conflicts with the usage of the
    definition of reserved in the iSCSI document and the definitions coming
    from T10, specifically how to handle garbage in reserved fields.  I
    would suggest that a PDU format error in iSCSI is actually a PDU
    received that has errors in any defined fields, but does not require a
    reject if inconsistencies are found in reserved fields.  Also, the fact
    that some reserved fields require zeros, while others require ones seems
    odd, and will probably lead to more incompatibilities than the value of
    having dissimilar reserved field use provides.  If there is previous art
    that forces this difference than let's call that use of the field for
    what it is, versus calling it reserved.  My understanding of TCP network
    protocols is very weak, though, and there could be a really good reason
    why this mapping is happening, so please whack me with the stupid stick
    if necessary.
    
    The following are cases where 07 has lapses in the use of reserved
    fields:
    
    Page 44, under AHSType, bits 0 and 3-59 are declared Reserved, but not
    "must be 0".  But also strangely here, it seems that AHSType is an
    eight-bit field, that has 64-bits worth of explanation.  Am I reading
    something wrong here?
    
    +++You must have been confused by the B - it means bit. The first 2 bits
    have special meaning while the rest are a coded field with 64 value+++
    
    Page 45, byte 2 of word 0 of op-code 0x01 is declared Reserved, but no
    requirement for zeros (aside from the directive in Section 2).
    
    +++There is a general requirement sated in the last statement before 2.1
    that reads:
    Any bits not defined MUST be set to zero. Any reserved fields and values
    MUST be 0 unless specified otherwise.
    ++++
    Page 49, bits 5 and 6 of Flags are declared as Reserved, but no
    requirement for zeros.  Also, bit 7 is not even declared even though the
    table above (pg 48) shows bit 7 as a 1.  Does this mean bit 7 falls into
    the odd category of a reserved field that must be 1?
    
    Page 49, bits 80-ff of Response are declared as "Reserved" for
    Vendor-unique responses.  Now most developers would interpret this
    correctly, but the use of the word reserved here could lead some into
    thinking only 0's are allowed, or must be checked for 0's.
    
    +++ I doubt that somebody would really think so but if you mean to suggest
    another wording please do so +++
    Page 51, both 2.4.7 and 2.4.8 declare that if the S field is 0, then the
    two mentioned fields are reserved, but no requirement for zeros (aside
    from the directive in Section 2).
    
    Page 53, the definition of Reference Task Tag or Reserved shows that a
    reserved (even though specified) field need not be 0 (aside from the
    directive in Section 2).
    
    Page 80, bytes 0 and 1 of word 8 show CID or Reserved, but no
    requirement for zeros (aside from the directive in Section 2).
    
    Page 84, definition of Bit S, says 'otherwise, it is reserved,' but no
    requirement for zeros (aside from the directive in Section 2).
    +++ all requirements for 0 are covered y the general statement +++
    Thanks,
    Bob
    
    Robert Griswold
    Technologist
    Crossroads Systems, Inc.
    512-928-7272
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:02 2001
6315 messages in chronological order