Subject: [Ips] format errors

From: "Buck Landry" <[email-masked]>
Date: Mon, 25 Oct 2004 17:35:43 -0500

Hi folks.  I'm confused about exactly what an initiator could send that would be considered a "format error" -- as defined in rfc 3720 6.6, something that would force a target to "immediately terminate all transport connections in the session".  I assume this means w/out sending a Reject or Asynchronous Message first.

For example, from 6.6 a "format error" can be:
a)  Illegal contents of any PDU header field except the Opcode
          (legal values are specified in Section 10 iSCSI PDU Formats).
<<<

But in 10. I see:
Receipt of reserved code values in defined
   fields MUST be reported as a protocol error.
<<<

.. and "reporting" a protocol error sounds like issuing Reject, which isn't the same as immediately terminating all transport connections.  So what exactly is "Illegal contents", then?

In 6.6 we also have:
b)  Inconsistent field contents (consistent field contents are
          specified in Section 10 iSCSI PDU Formats).
<<<

.. but the only reference to 'consistent' I see is in 10.7.4,
If the Target Transfer Tag is
   provided, then the LUN field MUST hold a valid value and be
   consistent with whatever was specified with the command
<<<

... and this specific case seems to be covered by Reject w/"Invalid PDU field" in 10.17.1...
Note 2: (...) Some examples are invalid TTT/ITT, buffer offset, LUN
   qualifying a TTT, (...)
<<<

Also, 3.2.4.3 says 
Using inconsistent field values is considered a protocol error.
<<<

... does it actually mean to say "format error"?  Because if it was *merely* a protocol error, we could just Reject the PDU w/"Protocol Error" and be on our merry way, right?

I apologize for my confusion in advance; and thanks for your consideration,
--buck

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 28 Oct 2004 12:22:48 -0700

Hi Buck,

Let me attempt to categorize the possible PDU contents as we saw them 
when the RFC was written.

1. Legal values - PDU header field values defined and sanctioned by the 
RFC as usable.
	- E.g., opcode values.  One should process them per the RFC.

2. Reserved values - PDU header field values defined by the RFC but 
explicitly set aside for future use.
	- E.g., reserved opcode values, one should reject these
           with a protocol error.

3. Illegal values - PDU header field values undefined by the RFC
	- One should consider these as format errors.

4. Incorrect values - values of a PDU header field variable that the RFC 
does not put restrictions on (e.g., ITT, LUN for a TTT), but currently 
is known by initiator/target to be incorrect/invalid/non-existent.
	- Basically the cases covered by the "Invalid PDU field" Reject.

5. Inconsistent values - Cases where one PDU header field value 
disagrees with a different PDU header field value.
	- E.g., in a SCSI command PDU, ExpectedDataTransferLength
           != 0 and/or BidirectionalReadExpectedTransferLength != 0,
           but R = W = 0.  One should consider these as format errors.

Now, coming to the sentence in 3.2.4.3 that says "Using
inconsistent field values is considered a protocol error", it is 
unfortunately a bit loose in that it unintentionally uses the keyword 
"inconsistent" claimed in the format error description (6.6).  However 
notice that the text that precedes is actually decribing a category#4 
error - i.e. an incorrect value.  So the text is basically describing 
the right semantics - some protocol error had happened.  This section 
doesn't tell you what to do with such an error (and that's a good 
thing), 10.17.1 provides that information - respond with an "Invalid PDU 
field" Reject.

Hope that helps.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com