FN in CIP header of SBP-2

Stephen Finch/SSI1 Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com
Fri Jun 27 03:56:37 PDT 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Stephen Finch/SSI1 <Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com>
I'm trying to put bounds on the CIP parameters and their capabilities.  So
I have more questions.  Once I see the answer clearly and see that there 
is concensus, I'll attempt to propose changes to SBP-2 to document
and/or restrict interpretations so that the industry will avoid incompatibility.

1.  During the life of a channel, can FN ever change?  If so, I'd assume that
it can only change on a source packet boundary.  And, yes I know that
for MPEG this won't happen, but is anyone planning on using these capabilities
for other things?  E.g., a printer whose source packet might change from 
scan line to scan line?  If it does change, then (obviously), one could not
mix blocks of one source packet with blocks from another in the same
1394 packet. Right?

2.  Present definition of a stream is one or more channels.  I've also heard
rumors (desires?, prayers?) that a stream will only have one channel EVER.
I assume that multiple channels is the intent.  Can/should an implementation
restrict the number of channels (a max value) in a stream? Say 2, 4, 8 or ???
Are there any real-world usages that can be a guideline?

3.  Assuming multiple channels are in a stream, can FN be different for 
each channel? Again, my assumption is yes, since each channel is a separate
1394 packet and has its own CIP.

4.  Assume a device can support multiple streams.  If one stream is processing
channel "n", can it reject a request to process the same channel number on 
the second stream?  By process, I mean either listen or talk.  Two streams
talking on the same channel is obviously improper, but if a device is sending
on channel "n" and has a second stream which wishes to listen on channel "n",
then I have a problem as links/phys today can not receive what they are sending
and I don't think they ever will.  So this mode would have to be accomplished 
outside (above) the link/phy layers....  Yech!

5.  Other than taking the data_length field from the 1394 isoc packet header,
subtracting 8 (lenth of CIP in bytes) and dividing by dbs, is there anyway to
determine how many data blocks will be in the packet?  Assume no.

Enough for now.  And, yes, I have a few thousand more....

steve finch
silicon systems inc.
714 573-6808

* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list