Subject: SAS and iSCSI

From: Andre Hedrick <[email-masked]>
Date: Sun, 1 Sep 2002 17:37:17 -0700 (PDT)

Hi Julian et al.

Give these are both "SCSI" type transports, what are the means to add
future SAS extentions and opcodes to the expected final version of the
working group document?

Would this be considered a vendor specific issue.

Regards,

Andre Hedrick
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

---

From: [email-masked]
Date: Mon, 2 Sep 2002 13:36:41 -0400

If the extensions and opcodes use the SCSI CDB and associated
data movement paradigm as defined by T10, no modifications
to the iSCSI specs should be necessary.

It's hard to be more specific without more details on what
is specifically of concern.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Andre Hedrick [mailto:[email-masked]]
> Sent: Sunday, September 01, 2002 8:37 PM
> To: Julian Satran
> Cc: [email-masked]
> Subject: SAS and iSCSI
> 
> 
> 
> Hi Julian et al.
>

---

From: [email-masked]
Date: Mon, 2 Sep 2002 15:50:44 -0400

Andre,

> Will the additional opcodes and command descriptor blocks that
> are definied in SAS be transferred using additional header 
> segements by the iSCSI transport?

At the moment, the SAS specification
(ftp://ftp.t10.org/t10/drafts/sas/sas-r01.pdf) says:

	10.3 SCSI commands

	No SAS-specific SCSI commands are defined.

So, no iSCSI modifications are currently needed.

> This assumes there will be new opcodes as SAS is very much 
> ontrack to be an API for array management.

As long as those opcodes are SCSI opcodes that use SCSI CDBs
in a fashion specified by T10, no iSCSI modifications will
be needed.

> Specifically where many of the current
> management applications of heavily mated to SCSI and SAS is a means to
> grant them extended life, whereas the hardware is dying.  So 
> in order to acommidate such dependencies, the concern is to insure that 
> iSCSI will be adaptable to address their over short comings to be so 
> tightly tied to a transport layer and semi dependent of physical layers.

Yes and no.  To the extent that they depend on issuing SCSI commands,
receiving SCSI responses, etc., iSCSI handles that.  To the extent
that they depend on physical layer specifics (e.g., parallel SCSI
mode pages), they're broken and should be fixed, although I don't
think there are any fundamental obstacles to emulating parallel SCSI
mode pages in an iSCSI target to accommodate such brain-damaged
software if one really wanted to do so.

As for the original question about whether iSCSI AHSs (additional header
segments) would be used for SAS, the answer appears to be "only for
extended CDB formats defined by T10", something that iSCSI already
supports (AHS code 1).

Thanks,
--David

---

From: [email-masked]
Date: Tue, 3 Sep 2002 11:25:15 -0500

There are no new opcodes or CDB's in SAS.  The thing the questioner might
be thinking of is the additional SAS task management information located
after the header and before the start of the CDB in a command frame.  This
is unique to SAS, and I would not think it will appear as such in iSCSI.

Dave

                    Andre Hedrick                                                                                       
                    <andre@pyxtechnol        To:     Julian Satran <[email-masked]>, [email-masked]      
                    ogies.com>               cc:     [email-masked]                                                    
                    Sent by:                 Subject:     Re: SAS and iSCSI                                             
                    [email-masked]                                                                                   
                    .edu                                                                                                
                    No Phone Info                                                                                       
                    Available                                                                                           
                                                                                                                        
                    09/02/2002 02:04                                                                                    
                    PM                                                                                                  

Julian and David,

Thanks for the reply and update, I guess the second part never made it to
the reflector.

Will the additional opcodes and command descriptor blocks that
are definied in SAS be transferred using additional header segements by
the iSCSI transport?

This assumes there will be new opcodes as SAS is very much ontrack to be
an API for array management.  Specifically where many of the current
management applications of heavily mated to SCSI and SAS is a means to
grant them extended life, whereas the hardware is dying.  So in order to
acommidate such dependencies, the concern is to insure that iSCSI will be
adaptable to address their over short comings to be so tightly tied to a
transport layer and semi dependent of physical layers.

Cheers,

Andre Hedrick