[T11.3] FCP-4: Continuously Increasing SEQ_CNT

Jim.Coomes at seagate.com Jim.Coomes at seagate.com
Mon Nov 6 13:52:23 PST 2006

There is Continuously Increasing SEQ_CNT and there is Continuously
Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
Sequences and across streamed Sequences. The other Continuously Increasing
SEQ_CNT is established at port login and is Continuously Increasing SEQ_CNT
across the whole Exchange.
As SCSI FCP is basically an interlock protocol, what is the gain in
Exchange Continuously Increasing SEQ_CNT for error detection? If the
command is lost, there is no response from the target. The host has to
time-out. If a write data frame is lost, it is detected by relative offset
or SEQ_CNTat the target. If a transfer ready is lost, the host or the
target has to time-out. If a read data frame is lost, it is detected by
relative offset or SEQ_CNT at the host. If the ending response is lost, the
host has to time-out.
These detection scenarios apply to bidirectional commands also.
Exchange Continuously Increasing SEQ_CNT does not change this behavior.
What is the gain in using Exchange Continuously Increasing SEQ_CNT?
FC has a large installed base of which many devices do not support Exchange
Continuously Increasing SEQ_CNT. This would support not making Exchange
Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
warning that it could be a time delay before Exchange Continuously
Increasing SEQ_CNT could be available widely.
----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
	     Claudio DeSanti						   
	     <cds at cisco.com>						   
	     Sent by:							To 
	     owner-t10 at t10.org	       "Craig W. Carlson"		   
	     No Phone Info	       <craig.carlson at qlogic.com>	   
	     Available							cc 
				       Bob.Nixon at Emulex.Com,		   
				       David.Peterson at mcdata.com, T10	   
	     11/03/2006 03:38	       <t10 at t10.org>			   
	     PM 						   Subject 
				       Re: [T11.3] FCP-4: Continuously	   
				       Increasing SEQ_CNT		   
* From the T10 Reflector (t10 at t10.org), posted by:
* Claudio DeSanti <cds at cisco.com>
Craig, Bob, Dave,
there are functions defined in FCP-4, such as data overlay or certain
bi-directional commands, that are simply not implementable in Class 3
without the use of CISC. I bet that the devices you are referring to do
not implement these functions. I recommend to identify these functions
in FCP-4 and either:
a) obsolete them; or
b) clearly state that use of CISC is required to implement them in Class 3.
In addition, the usage of CISC greatly simplifies error recovery in
Class 3. We should encourage this behavior moving forward. I recommend
that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
not its use. CISC should be mandatory to support and optional to use in
FCP-4. In this way we set a good path for the future, while allowing
complete interoperability with FCP-3 and older devices that do not
support CISC. To ease this interoperability FCP-4 may also recommend to
not use CISC by default. But mandating its support in FCP-4 devices, we
achieve that when connecting FCP-4 only devices CISC may be turned on
and used, with all its advantages.
Craig W. Carlson wrote:
> I’d have to agree with Bob on this one. We are aware of devices which
> cannot support CISC, and which would seriously break if presented with
> it. A change such as this (either a or b) could create havoc with
> device interoperability.
> +Craig
> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>     Dave,
>     Despite the potential value of CISC to FCP operation in Class 3,
>     we must advise against requiring or even recommending it.
>     In our interoperability testing, we have discovered there are
>     devices with significant installed base that do not behave
>     properly when actually presented with CISC. Unfortunately, they do
>     not reject an N_Port Login that offers CISC, so this problem is
>     not discoverable.
>     Even recommending CISC in a standard would therefore increase the
>     incidence of interoperability problems with use of Fibre Channel.
>     - Bob Nixon, Emulex alternate representative
>     -----Original Message-----
>     *From:* t11_3-bounces at listserve.com
>     [mailto:t11_3-bounces at listserve.com]
>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>     *Sent:* Sunday, October 08, 2006 12:34 PM
>     *To:* t10 at t10.org
>     *Cc:* t11_3 at t11.org
>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>     Howdy All,
>     At the last FCP-4 working group meeting I presented a proposal to
>     request the use of continuously increasing SEQ_CNT (CISC) for
>     Class 3 service.
>     While most believe requiring continuously increasing SEQ_CNT for
>     Class 3 service is a good idea, one vendor indicated that none of
>     their implementations support CISC, and another vendor was
>     concerned about the requirement.
>     As such, we have the following options:
>     a. require CISC for Class 3 service. This means that existing
>     implementations can claim compliance to a prior standard (e.g.,
>     FCP-3);
>     b. specify that CISC should be used for Class 3 service;
>     c. no change (i.e., CISC is not required except for streamed
>     Sequences).
>     My preference would be option a.
>     What say ye?
>     ...Dave
>     (no disclaimer)
>     _______________________________________________
>     T11_3 mailing list
>     http://mailman.listserve.com/listmanager/listinfo/t11_3
> ------------------------------------------------------------------
> Craig W. Carlson mailto:craig.carlson at qlogic.com
> QLogic Corporation (952) 932-4064
> 6321 Bury Drive
> Eden Prairie, MN 55346
> ------------------------------------------------------------------------
> _______________________________________________
> T11_3 mailing list
> http://mailman.listserve.com/listmanager/listinfo/t11_3
* For T10 Reflector information, send a message with

More information about the T10 mailing list