| DISCUSSIONS: |
- From May 18th, 1998 Meeting in Crystal City, VA
- Command Set Discussion
- Possible commands to be included are:
- Send buffer
- Get buffer
- Set parameter
- Get parameter
- The following parameters were identified:
- Read only: SND BUF cmd queue size
- Read only: GET BUF cmd queue size
- Read only: MAX SEND BUF data block size
- Read only: MAX GET BUF data block size
- Read/write: Unsolicited Status Enable Write Timeout [?]
- Encoding Issues:
NOTE: The items marked with "[?]" indicate questions by the group about whether it is necessary or not.
- For each command:
- 1 byte for command and command result
- 1 byte for sequence number unique to command [?]
- Send buffer
- 32 bit length
- 1 bit out-of-band
- 1 bit end of message [?]
- 1 bit abort message [?]
- Get buffer
- 32 bit length
- 1 bit out-of-band
- 1 bit end of message [?]
- 1 bit abort message [?]
- 1 bit more data available
- Get Parameter and Set Parameter
- 16 bit parameter ID (add OUI to parameter tag?)
- 64 bit parameter value (parameter list with tags?)
- Queue Bits:
- Suggestion that we consider reserving two bits in the ORB for a "queue ID" that identifies one of four possible values:
- 00 Control (blocks; no forward progress until done)
- 01 Inbound (maximum depth NI)
- 10 Outbound (maximum depth NO)
- 11 Vendor-dependent (maximum depth NV)
-
- Group felt this idea was more flexible, but a few people were concerned that it creates unnecessary complexity.
- Proposal to reserve only 1 "queue" bit.
- Also idea that instead of knowing the depth of each queue, only the total maximum is needed.
- As long as the initiator doesn't exceed this maximum, there will be sufficient room to avoid blocking.
- SHPT Command Set Proposal
- Introduced idea of a "channel management agent" to the previous SHPT draft.
- Four different command categories:
- Handled by WRITE execution agent
- Handled by READ execution agent
- Service dependent
- Channel management commands
- Each of the command formats was presented.
- Issue:
- One outstanding issue to be resolved is the method for handling "channelization."
- SHPT uses two queues per channel.
- (It may be possible to have many channels per Login, but do we want it? No.)
- Do we benefit by having more than two queues?
- Interoperability issues if there are a veriable number of queues.
- Encoding Summary - after all command set discussions
- CDB encodings
- 1 bit queue identifier
- 7 bits command field (save range for vendor-dependent command)
- 24 bits OUI
- parameter commands
- 8 bits parameter identifier
- parameters
- 16 bits max "across both queues" (max task set size) - read-only
- 32 bits max data size per ORB (inbound) - read-only
- 32 bits max data size per ORB (outbound) - read-only
- 2 bits duplex mode: bi-di, send only, receive only, off (reserved) -read/write
- status block
- 8 bits error code
- 32 bits residual
- 1 bits tag field (out-of-band)
- 64 bits vendor-dependent information
- Issues:
- Although Cross Login may not be necessary, is it the best solution for peer-to-peer? A few individuals felt that we should not spend time exploring Cross Login further.
- The group discussed the possible needs for segmentation and reassembly of single commands that may span more than one ORB buffer and issues related to handling multiple commands within a single ORB buffer. If we can depend on there only being one message per buffer, there might not be any need for the "end of message" bit.
- The idea of a sequence number for the buffer was rejected until someone could come up with a clear proposal for using it under error recovery situations.
- The group agreed that we should explain that the initiator should always post a read as soon as it is able. Given this policy, it is probably not necessary to have a "more data available" bit.
- Suggestion that parameters should be obtainable via Get Parameter as a list. This could be achieved in a (TLV) format. For Set Parameters, the same TLV format could be used. Each tag would identify a specific parameter. Perhaps this could be accomplished.
- Unique Tag values will be defined within the scope of a PWG OUI? (TBD)
- From July 6th, 1998 Meeting in Monterey, CA
- Command Set Discussion
- Review and discussion on proposal document - PWG 1394 Transport Command Set Proposal Revision 0c.
- (This document is available on the web site)
- Queues:
- Discussion:
- Should the usage of each queue be specified (e.g. Read and Write) or left arbitrary?
- Should we allow a vendor to extend the number of queues within a single Login?
- Suggestion that if an implementer would like to extend the number of queues, it should be accomplished by additional Logins.
- Suggestion that we should limit a given Login to a (simple) bi-directional communication "pipe."
- (The idea of two independent non-blocking queues was originally proposed because SBP-2 doesn't inherently support this capability.)
- It is intended that the group will focus on providing the equivalent of a bi-directional transport.
- Issues:
- Should we eliminate the queue (q) bit, and just use the direction (d) bit only? Is it a reasonable assumption that the direction is equivalent to the queue id? It was decided that this issue is dependent on error recovery, and it was deferred.
- Summary:
- The group agreed to limit the number of queues to 2; one for Initiator-to-Target transfer and one for Target-to-Initiator transfer.
- Extensibility:
- Points Raised:
- To what degree should we provide extensibility?
- Do we really need to support a mechanism for vendor-specific transport commands? Interoperability is key concern.
- Point noted that the group agreed to limit the number of queues to 2. The number of queues is not extensible.
- Suggestion that vendor-specific commands could be useful as a method to fix bugs.
- Most of the other attendees felt that this was not a good enough reason to include support for vendor-specific commands.
- It was suggested that vendor feature differentiation could (and should?) be achieved at higher levels.
- Summary:
- The group agreed that a Command OUI is not necessary (at least for this version of the Profile.)
- No vendor-specific commands or parameters will be supported.
- Any extensions will only be possible through the PWG standards group by revision of the document.
- Parameters:
- Discussion:
- SBP-2 Login is not extensible, suggestion that the PWG Profile should include a Login Response, followed by an exchange of additional parameters. Also noted that both the Target and the Initiator should know each other's capabilities -- at least to help resource allocation efficiency.
- Suggestion that the commands Get Param and Set Param List should be executed before data transfer, similar to a "connect" process. This suggestion was later expanded to an Open command that could establish other items that would be necessary for managing a connection.
- Issues:
- When can parameters be set and/or changed?
- Summary:
- Volunteer to address the Open negotitation sequence added to list of proposals.
- Other Issues (belong here or in Model?):
- When should a Target complete the Store Data Command Response?
- Does it make sense to use the names "Store Data" and "Fetch Data" for commands?
- Would it be better to just have a single "Transfer" command, with the direction (d) bit used to indicate which way the data should be transferred?
- Should the q bit be placed in the status block?
- Should we keep the Max Data Size Per Fetch ORB parameter?
- Should we keep the Max Data Size Per Store ORB parameter?
- What should happen to Fetch Data and Store Data commands that are in or added to the active task set when a data flow direction is disabled?
- Should we put "last acknowledged Sequence Id" in each status block?
- Perhaps we should add some attributes and features to the Unit Directory? This might be a mechanism (for example) to communicate the maximum buffer size of the Target.
- Is queue implied by direction bit?
- Summary:
- 2 queues only
- No vendor-unique extensions (for this revision)
- no CMD_OUI
- no Parameter_OUI
- Provide only equivalent bi-directional transport - MSG (packet) and Stream
- Error recovery
- 16 bit increasing Sequence Ids
- 14 bit size for Max Task Set
- From August 17th, 1998 Meeting in Toronto
- Command Set Proposal
- Review and discussion on - Revision 0d of the PWG 1394 Transport Command Set Proposal.
- (This document is available on the web site)
- Command Set Discussion
- Discussion:
- Comment that the Open and Close Transport commands are not symmetrical. The Transport_Open command is issued for both queues, but the Transport_Close is issued for only one queue at a time. Explanation that the reason for this was to allow the Initiator to indicate that no more writing to the write queue will occur, but reading will continue on the read queue. Discussion on reason to see if it was a valid situation. Not able to identify a specific situation to justify the capability.
- Suggestion that the Transport_Close command is redundant to the Logout command. (Although unsolicited status could be generated before a Logout, it was not felt that this was a reasonable event.) If Transport_Close is eliminated (because it is redundant to Logout), this would also create an asymmetrical situation for Transport_Open.
- The Get_Transport_Capabilities command was discussed. Noted that when a Target responds with certain transport capabilities, it must reserve those capabilities for the duration of that Login.
- Suggestion to keep the Close command to allow some kind of acknowledgment. Using Logout does not provide any chance for a reply. Discussion ensued.
- Suggestion that any desire to abort a large print job should be handled at a higher level_perhaps on a job cancel basis.
- Issues:
- No consensus was reached on keeping the Close command.
- Should we have a Transport_Close command of any type_either applicable to a single queue or both queues?
- What behavior should occur after a Close and after/during an Open?
- If we eliminate the Transport Close command, should the Open command be renamed?
- What should be done about the following case? An initiator opens a connection, carries on a conversation, closes both queues for communication, and then does a TARGET RESET? Presumably, this would allow another TRANSPORT_OPEN to be issued without having the initiator Logout, though it would affect all other initiators logged in to that target by generating a UNIT ATTENTION condition. Because we must support TARGET RESET to be SBP-2 compliant, this situation must be supported as well.
- Should we support ABORT TASK?
- Target has the option to ignore the ABORT TASK command_once it has fetched the ORB.
- Based on current design, it would seem that if an Initiator Aborts a task, it must Abort all the remaining ORBs in that queue, and must resubmit them with the same sequence IDs.
- What is Initiator behavior if the Target responds to an Abort Task with _I completed the ORB_ (instead of acknowledging it as a Dummy ORB?) This condition might cause the Target to process data that shouldn't have been. This can cause problems for a printer data stream.
- Abort Task Set is used by some OS stacks in response to a timeout condition. The group needs to examine and understand what the condition details are.
- Summary:
- The group agreed to change the Transport_Close to apply to both queues. Noted that once a Close is done to both queues, there is nothing that can be done next - except a Logout.
- The PWG Profile will state that the client SHALL NOT issue an Abort Task (because we cannot guarantee the execution of an Abort Task request, and this might cause unpredictable behavior.) [It was also noted that Microsoft does not support the Abort Task capability.]
- The group agreed to add a new parameter to indicate that the Initiator will maintain data buffer content integrity across Bus Resets (to address the proposal made by Ueda-san earlier.)
- The Profile document should include an explicit statement on the padding order and the placement of data bytes less than a full quadlet (e.g. a diagram showing a five-byte data value.)
- Motion made, seconded, discussed and unanimously approved to include the latest revision of the Command Set document into the Profile document.
- From August 17th, 1998 Meeting in Toronto
- New Command Set Proposal
- Proposal for additions to the transport command set.
- Document is available as: proposal-cmd-1a.pdf
- Key Points:
- Addresses issue of handling dynamic logical channels on one logical unit (LUN.) The proposal attempts to provide a method for dealing with dynamic logical channels.
- The highlights of the new features in the proposal include the following:
- each queue may contain input ORBs and output ORBs
- single LUN may provide logical channels
- logical channels are allocated dynamically on demand
- the initiator may place parameter in data buffer of an ORB or CDB structure of the ORB
- commands are abstracted from ORB data structure
- Discussion:
- Queue Usage:
- Noted that the proposed method of using two bi-directional queues is similar to having four queues in the existing model. The reason the existing model does not have bi-directional queues is to avoid blocking.
- Noted that the current model is extensible to support more than two queues. (Could the new proposal features be accomplished by using four queues within the existing model?)
- Question of what problem is addressed by this solution?
- It solves the need for providing multiple channels using one LUN.
- Suggestion that the existing model can support multiple LUNs without needing to have multiple entries for each LUN in the Config ROM. The additional channels can be discovered—and/or established—through other means.
- (However, at least one individual believes that a current implementation may not support this capability.)
- New Commands:
- In reviewing the new commands, it did not appear that any of them offered additional useful capability—at least with regard to the existing requirements.
- Idea of multiple channels over a single LUN seemed to get confused with some Legacy features during discussion. One part of the proposal was to include three Printing Class-specific commands:
- GET_DEVICE_ID
- SET_LEGACY_ENABLE
- SOFT_RESET
- Group feeling was that the command for getting a device id is more appropriate for the O/S to define.
- Other Topics:
- Another suggestion was that the 1212r group add a "Plug 'n' Play" string leaf node to their specification.
- Topic of SOFT_RESET concluded in the observation that there is no standard behavior across current (legacy) implementations. Therefore, there is no "standard" that can be defined in this area.
- Suggestion was that both SET_LEGACY_ENABLE and SOFT_RESET could be implemented as vendor-specific capability.
- Question raised regarding whether the group should attempt to specify anything about interoperable printing between 1394 devices. Suggested that it would be nice to identify a standard, interoperable scheme for printing services to achieve this result. This topic was deferred for later discussion.
- Legacy Printer Support:
- The discussion led to the general topic of supporting legacy printers for 1394, and the possible use of dongle devices for accomplishing such support.
- Decided that it was out of scope of the current Profile goals.
-
- Summary:
- Any individual or company that is interested in supporting a (legacy) 1284 device with 1394 should develop a separate Profile document that would specify the appropriate details.
- The 1394 PWG will not burden the development of the Profile document with the inclusion of legacy support issues.
- This proposal was rejected for inclusion in the existing Profile document.
|
