1394 PWG - Issue No.980302-012a

1394 PWG - Issue No.980302-012a Back to the Issues Page

ISSUE NO.:	980302-012a	NAME:	SBP-2 Model	STATUS:	TBD
RESOLUTION:				DATE:	TBD
ORIGIN:	03/02/98 Meeting in Austin, TX
DESCRIPTION:	Based on vote at Austin Meeting, the group decided to focus on an SBP-2 solution. This closed 961206-001. This issue covers the printer model in an SBP-2 environment.
DISCUSSIONS:	From March 2nd, 1998 Meeting in Austin, TX SBP-2 Data Flow discussion see file "sbp2_data_flow.pdf" Overview: Need to extend the reconnect timeout on SBP-2. Extended_timeout to be proposed to the SBP-2 working group. Issues: "Invalid_Login_ID" shouldn't be overloaded for the Target Controlled End of Session. Concern that reverse channel (target to initiator) is inefficient when for unsolicited data case. Profile issue-- Latency in handling unsolicited data. How frequently do we expect 'urgent' unsolicited data or is this an exception case and we shouldn't compromise the performance of the general case. From April 6th, 1998 Meeting in Portland, OR SBP-2 Model Discussion Desired Goal: Service with one LUN, non-blocking bi-directional communication with a single login. SHPT Presentation SHPT Proposal Overview: Offers better efficiency over the Ordered model. Other schemes either: Create redundant communication between Initiator and Target Impose latencies that are inefficient in use of bus bandwidth Impose extra workload on both the Initiator and Target to re-schedule tasks. SHPT model has concept of a "queuing model" that uses the SBP-2 unordered capability over a single Login. Both the Initiator and Target maintain two separate queues, one each for Read and Write requests. Independent activity can occur for both Read and Write execution, thereby eliminating the need for a pending Read transaction to wait for preceding Write transactions before it executes. Major point - Target is responsible for the re-ordering of the ORBs after an error recovery. Issues raised SHPT needs to know the depth of target queues. Opinion was that Initiator doesn't need this info. Is it reasonable to modify the SHPT model to eliminate the need for this knowledge? Two alternatives now exist for the single login method: SHPT and using the Ordered model. "best of both worlds" discussion Model the device as two message queues Use the Ordered task model Initiator only queues commands guaranteed to complete Explicit queue status (flow control) sent on each command completion within completion notification Unsolicited Data Available sent only when task list is empty Add sequence id to know where you can resume fetching contents Resolution Group adopted the Unordered execution model of SHPT as our direction of development and to use it as the basis for our continued work on the Imaging Device Communication Profile by 11 yes votes, 1 no vote, and no abstentions. Noted that the Unordered model offers more flexibility and better performance over the Ordered model. SBP-2 penalizes idle devices with start-up latencies, the Unordered is preferable. There are more cases of the Ordered model being idle than the Unordered model. LUNs, Logins, and Units How should we distinguish between Units and LUNs? People agree that the printer language interpreter and status can be combined into a single Unit. There was not agreement if they should also be combined into a single LUN. Other issues: How can we encode multiple PDLs? How do we identify the different types of services? Do we need to provide a mechanism to allow multiple logins (from the same Initiator) to the same type of service? Example is multiple client applications that want to access the same service on the same function (like SNMP). Even a separate Unit dir will not solve the limitation of SBP-2 one login between a Unit and the initiator. Proposal of a "Login-less datagram" service as a beneficial feature. Issue: Size of actual returned data. (look at Message Request / Message Response) Discussion of a "login server" to dynamically assign LUNs. This would allow an initiator to dynamically connect to a service on a target. Issue: Will commercial OS vendors support this idea? From May 18th, 1998 Meeting in Crystal City, VA SBP-2 Printing under PC OS. 2 or 3 OS reportedly will offer SBP-2 support this year ('98) (Windows and Macintosh.) Main Points discussed: One idea is to have the 1394 PWG node provide another LUN in configuration ROM that would be used as a "1394 PWG LUN controller." Another comment was that OS vendors were changing implementations and removing certain limitations (i.e only supporting LUN 0). General poiint was that we should not necessarily constrain ourselves by existing implementations. Issues: Is it possible to provide upward compatibility with the 1394 PWG future standard. Will the existing driver stacks provide support for the 1394 PWG standard. We need to define what requirements and assumptions we have with regards to the platform SBP-2 implementation. SBP-2 Model Discussion Desired Goal: Service with one LUN, non-blocking bi-directional communication with a single login. Dynamic LUN Issue Dynamic LUNs: Discussion at the previous meeting that we use a Dynamic Logical Unit scheme to multiplex applications to device functions. For example - in order to implement a status monitoring function via a single Unit Directory, some type of multiplexing must occur above SBP-2 to make the function available simultaneously to two or more applications on the same host. At the previous meeting, it was proposed that applications Login to LUN 0 and then receive the Dynamic Logical Unit that will be used for that application's connection. Groups decided to try and tackle the definition of Service and Function. (Working definitions added to terminology issue - 970514-008) Configurations: Two different configurations for target models of three separate functions (print, scan, fax) within a device: three separate nodes one single node multiplexed to three separate functions Both of the above configurations led to an architectural model of a Root directory pointing to a Unit directory (Function) pointing to a LUN (Service). Issues raised: Status and control span multiple Functions/Services (such as printing and scanning in an MFD.) Alternative idea is to keep the status and control mechanism separate for each individual Function/Service. It would be possible to have all of them report as busy if any one of them is active. One possible model of a multi-drive CD device was described as two separate entities: the actual drive and the CD changer (i.e. control) mechanism. One LUN could be a "controller" that is responsible for (all) the other LUNs. If synchronization between Functions is necessary, this will have to be done outside SBP-2. Once you need a separate synchronization mechanism, you may as well have it also be responsible for multiplexing to the separate Functions. Summary: Dynamic LUNs are not necessary. Do not want to modify SBP-2 or create a "hack" on top of it. In order to support multiple Logins from the same initiator to the same target on the same LUN, you must provide a multiplexing layer above the PWG profile that will provide this functionality. From July 6th, 1998 Meeting in Monterey, CA SBP-2 Model Discussion Error Recovery Model: Presentation on Error Recovery Requirements: Initiator shall keep the contents of the data buffers associated with the ORBs in the linked list, and maintain the correspondence of the data buffers to a Sequence Identifier. Target must guarantee that it does not execute any data or command twice. ORB Completion: Need to maintain a Sequence Id for the ORBs. It is not necessary for every ORB to have a status notification sent. Send status for a subset of the ORBs. Specifically, if a Sequence Id can be a maximum of 2n-1, it is necessary to have at least one status sent for every group of n ORBs that have been sent since the previous status. Based on the requeuing of ORBs, the Target can determine if the Initiator has received the most recently sent status block. If a Sequence Id is not used, the Target cannot determine if the Initiator has received the status block or not. General opinion was that this idea had merit. Issues: Does this solve problem of both writing from the Initiator as well as writing from the Target? Not clear that reverse channel was considered. Comment on maintaining negotiation of buffer size. (related how?) Question: Benefit (in terms of performance efficiency) gained by reducing the number of notification status blocks sent. The only comment was that "it really depends on the size of the data buffers." Further Discussion on Error Recovery Questions raised: Should we include a Sequence Id for the ORBs? What is the scope of the sequence number? Noted that the Target should not process more than 2n ORBs ahead of the last ORB for which the Target received an acknowledgment of completion status from the Initiator (where 'n' is the bit width of the Sequence Id.) Otherwise, it is possible that the Target could lose track of the error recovery information provided by the Sequence ID. Pre-fetching ORBs and the reliability of ORB pointers after a bus reset. Proposal to make Sequence ID eight bits wide, another to make it 16 bits wide. Summary: The group agreed to use a Sequence Id for error recovery purposes. The Sequence Id be sufficiently larger than the Maximum Task Set, the group agreed to 16 bits for the Sequence Id and 14 bits for the Maximum Task Set size. Open Issues: NEW GROUP ISSUE? Noted that the group needs to define a unit attention status model. What should be the initial value for the Sequence Id? Suggestion that the initial value could be inferred based on the first ORB on each queue after a Login or an abort task. Other idea that some "initial process" be defined to ensure a specific value for the first Sequence Id. No resolution. Noted that the ORB Sequence IDs might have "gaps," because of the use of Abort Task and Abort Task Set commands. Is it necessary to generate a notification for each ORB to handle error recovery properly? Groups decided that those with more knowledge of issue should spend time after the meeting to examine this question more closely and come back with a proposal. Noted that without a timeout value (for an ORB completion notification), there is no way a host can know the lifetime of an ORB. Solution is that if the Initiator wants to free the resources associated with an ORB before the completion notification has been received, an abort task command should be issued. Noted that we should define (or negotiate) timeouts for: Abort task Abort task set Logical unit reset Target reset Notification: Discussion on problems that can occur if a status notification (or its acknowledgment) can be lost. Points Raised: Doubt expressed about the frequency of this condition ever happening. If it is an extremely unlikely event, perhaps it is better to simplify the recovery process as much as possible. Should we set the notify bit to one (1) for every ORB? Do we need to always notify completion of every ORB? A "well-partitioned," layered SBP-2 driver does not have sufficient knowledge about the ORBs in the queue when using an unordered model. If the driver did have this knowledge (by examining the q bit, for example), it would be considered "munging" (combining) the different layers. Assumptions: A direct implication of using the unordered model is that every ORB must have completion notification. Issues: Can we enforce a notification policy for each ORB? Is this capability acccessible to a layer above the SBP-2 stack in a given OS implementation? The latest SBP-2 specification does not explicitly addressed this issue. No clear statement that says the Initiator must set the notify bit when using the unordered model. Discussion regarding PWG Profile policy - 3 alternatives identified: 1. Require an Initiator to set the notify bit on every ORB 2. Require the Target to always give completion notification 3. Allow for the possibility of "monolithic" (multi-layered) Noted that SBP-drivers are implemented without saying anything additional beyond what is already specified in the SBP-2 specification. After more discussion, the group agreed that the PWG Profile document would not make any additional, explicit statements on this issue other than to follow the SBP-2 specification. (Agreed? - still valid?) Connection Open/Close Connection - "connection meta-data" initial values for Sequence Id numbers connection type completion policy maximum record size How can a Target close a connection (i.e. unsolicited status? - was noted as out of scope previously) Issues Raised: How will Target initiate close (unsolicited status)? How to communicate/clear UNIT ATTENTION? From August 17th, 1998 Meeting in Toronto SBP-2 Model Discussion Error Recovery Model: Gap Control Overview: "Enforced sequential command tag" approach is inefficient for command set recovery, because there can be overhead introduced even in normal operation situations. Need Gap Control method to maintain coordination and recovery of command processing between the Initiator and Target. To avoid the inefficiency two rules are proposed: Target determines whether the command is ahead or behind current position based on the sign of the distance between them. Initiator is responsible to keep the actual sequence of tasks in the task list to be recognized correctly by the target. Discussion: Different situations that may occur in an error recovery situation. Process of aborting a task by using a _dummy orb_. Open Issues: Abort Task Set management function. What is correct behavior? Abort Task command can possibly cause problems. No guarantee that the Initiator will actually respond to the Abort Task request. Unresolved disagreement about how frequently this situation will really occur_and therefore how much efficiency is really gained by the proposal. Target transitions to a dead state Once a Target's fetch agent has transitioned to a dead state, how long will it wait for an Initiator to do error recovery before it takes action on its own? Can a Target take action on its own? What type of action? How long is a target expected to stay in a dead state? This issue is currently felt to be beyond the scope of the specification because it is application specific. If it needs to be resolved at a higher level, we may need to provide a mechanism to achieve it. Error Recovery - as defined in SHPT proposal Overview: A few optimization methods were proposed: use same physical memory for application buffers and transport buffers use same size buffer as 1394 transaction for error recovery sender can directly write data to buffer in receiver specifying the 1394 address For error recovery, the Initiator must keep the contents of the data buffers associated with the ORBs in the linked list, and the Target must guarantee not to execute any data and command twice. The Initiator must guarantee that the contents of the data buffer will not change over a Bus Reset. Proposal that a special value of 0 for Max_T2I_DATA_SIZE should indicate that the Target does not need to guarantee to hold and re-send data. (The Initiator will guarantee to maintain the contents over a Bus Reset.) Discussion: Noted that the value of zero is already used to indicate that no data will be transferred in that direction. Suggestion that another (new) parameter could be defined to indicate the capability proposed. Agreement that the capability to indicate to a Target that the Initiator will retain the data contents of a data block and its Sequence ID over a Bus Reset was a reasonable feature. Method for indicating this feature was deferred until the Command Set topic was addressed. Whether the contents of the page-tables for the buffer could be relied upon after a Bus Reset. Generally, people feel that the Target should re-read the page table (in case the pointers to the data contents have changed.) From September 28th, 1998 Meeting in Savannah, GA SBP-2 Model Discussion Development of and achieving consensus on a coherent model for the relationships of LUNs, Units, Services, and Functions continues to be an outstanding topic. Three alternatives were identified: Multiplex using only LUNs ("Pure SBP-2") one Login establishes one connection Login = connection from client to server Multiplex using LUNs and something above ("Hybrid") one Login establishes a session to a service which has or provides a multi-connection interface Login = all connections between all the clients from one Initiator to the Server on one Target Multiplex above LUNs ("1284.4-like") one Login establishes a conversation Login = the connection between all the clients from one Initiator to all the Servers on one Target Evaluation of three methods. (Diagram in Minutes) Discussion on the various merits of each method. Motion was made, seconded and passed without objection to focus on Option 1 - SBP-2 Native mechanism for initial discussion. A continued discussion on the characteristics and relationships of LUNs, Units, Services and Functions. Several of the concerns discussed were identified as "FDS (IEEE 1212r) issues." Printing Services Identified for consideration: PDL stream Postscript stream Status stream Query response "Box" status Fax send and receive Discussion on the various merits of each method. Group conclusion changed after this discussion that Alternative 1 would not be good because its use of LUNs to describe services "seriously conflicts with the understood models of SBP-2." The group could not define a consistent manner to represent services. Alternative 2.5 was then proposed for consideration: Multiplexing via "SHPT-like" mechanism (more than two queues per Login) Function Instance = Unit Login = connections between all clients of one Initiator to all services of one function instance Function discovery via FDS Service discovery via PWG commands Discussion concerning a mapping of Units to Services (each Service is a Unit), with each LUN being an "instance" of the Service. Sample services included: LPD TIPSI Telnet SNMP Summary Topic would be taken to the reflector and followed up at next meeting. From November 9th, 1998 Meeting in Tucson, AZ SBP-2 Model Modeling Units & LUNs to Functions & Services See presentation: tus_lun.pdf Key Points Queues, represented by the queue field in the command, are non-blocking bi-directional pipes. The Direction bit tells the Target how to manage the ORBs into its Data_In and Data_Out structures. Unit Directory represents a Function (i.e. Printer) A LUN represents a Service Service Discovery See presentation: svc_disc.pdf Definitions: Function: a label applied to a class of devices which provide similar related useful information. Services: an entity which provides some capability by accepting requests and generating appropriate responses. Relationship: Functions relate to a human perception of the device capability. Services relate to the mechanisms used to access the device capability. 1394 PWG model: A device may support one or more Functions A Functions may be accessed by one or more Services A Service may have specific attributes 1394 Node model: Module is the "box" containing one or more nodes. Node is an entity that supports one or more functions. Unit Directory is the software interface CSR is low-level H/W ConfigROM is Node Description SBP-2 Node model: Module is the "box" containing one or more nodes. Node is an entity that supports one or more functions. Unit Directory is the software interface defined by Spec ID CSR requirements defined ConfigROM is Node and Transport Description 1394 PWG Node model: Inherits SBP-2 model and extends it via the following concepts. Unit Directory defines a software interface for a function Logical Units (LUNs) provide unique socket endpoints which provide access to services. Defines PWG command set, ConfigROM, and the Multi-Queue Model Proposal: How to Identify Services Provided by a Target Provide High Level service Information in the Unit Directory One idea is to locate a Service Descriptor Block (SDB), 4 quadlets long, in the Unit Directory for each LUN Inline will be faster to parse. Contents of an SBD: LUN Information Existing LUN Key Service Identifier Values New Command Set specific Key Service Name String Standard Textual Descriptor Points to a text leaf Service Attributes Supported New Command Set specific Key A collection of SDBs in the Unit Directory provides a Service List Directory for that Function How to Access the Service Mapping the service to a LUN Creates a 1:1 mapping of the service to a LUN Multiple instances of a service Number of queues required per service Static or Dynamic Information Requirements: Using PWG OUI - define two new Command Set specific Keys: Service ID and Serivce_Attribute_Key Issues: Should a SBD be located in the Unit Directory or ina Unit-Dependent Directory? What if my function needs two services and I can't login to both? Discussion: Following definitions were offered / clarified: Function (Instance) = Unit Directory with LUN0 Service = Control protocol for independently operable component of function. Connection = Set of queue(s) that affords access to a service. Queue = Ordered set of ORBs that does not block with respect to other queues Multiplexing See presentation: ???? How to multiplex multiple logins from the same Initiator to the same service? 1- Channel multiplex on single login 2- Multiple logins with plural LUNs for the same service Summary: The direction that the 1394PWG is going is closer to #1, above. Applying the definitions proposed during the Service Discovery proposal, we can define a new queue definition: Queue 0: Command Queue for a given LUN. The command queue will handle Connect/disconnect requests for a requested service. Editor will generate a paper showing the connection algorithm and how it will fit into the profile document. Buffer Persistence Parameter See presentation: ParamPr1.pdf Issue: Requires Initiator to maintain buffer integrity across bus resets. Summary: Proposal: "ORBs are uniquely identified by the sequence number field. If, subsequent to a bus reset, an initiator reconnects and re-queues an ORB with the same sequence number value as an ORB active prior to the bus reset, then the initiator shall guarantee the following: the values of the direction bit and the data size, command, queue and command dependent fields shall be unchanged, and the data present in the buffer (if any) referenced by data descriptor shall be unchanged. Note that the ORB or data buffer or both may be at different addresses and that the speed and maximum payload characteristics may have changed as a result of the reconnection." Moved and passed by unanimous vote. Issue Review: Group chose the hybrid approach discussed in Savannah. Service discovery via PWG commands, not ConfigROM Connections established by a Service_ID Disconnects are identified by the Connection_ID Motion made, seconded and accepted to integrate the new definitions into the 1394 PWG profile. Other action taken on Model / Profile: Motion made to: "Remove MAXI2T from the current specification." Seconded. Per discussion there appears to be no compelling reason to keep it. Moved and passed by unanimous vote. Motion made to: "Remove MAXT2I from the current specification." Seconded. Per discussion there appears to be no compelling reason to keep it. Moved and passed by unanimous vote. Suggestion that queue 0 should have a higher priority than other queues. Since there is no concept of priority in the spec, we may need to address this. Discussion ensued�.. It was determined that there is no reason to do anything for this. From December 14th, 1998 Meeting in San Diego, CA SBP-2 Model Model and Command Set Review: See presentation: pwgpr43.pdf Note: separate from Profile document previously discussed. New ideas: Matched Request / Reply Orbs Commands and Actions Issues: Suggestion that we define "Channel" in this document. A Channel is a special case of a connection that uses two queues for bi-directional communication. Section 3.2 Target to Initiator Communications: How to start a T2I transaction? Options discussed: A T2I requires that Logins be maintained. Require maintaining the EUI-64 of the Initiator devices or some other method of notifying the requested device. Use a Message Request/Message Response to get the attention of the Initiator. Maintain a persistent Status FIFO. This option is not standard for SBP2. Discussion on how to handle changing the Max_Task_Set_Size (MTSS) after a Login. (Other presentation made at this meeting - see below). Options discussed were: Fixed per queue Global per Login (Transport Capabilities) New Dynamic command Connect Request/Reply Issue raised that I2T Disconnect may have different behavior than a T2I Disconnect. On a I2T the state of the connection (idle with no more commands or data) is known by the initiator. On a T2I Disconnect the Target does not know if the Initiator is "about" to send something. Section 4.3.3 Service_ID_String: Need to define requirements. Spawned Action item. Section 4.3.6 Result Codes: Four are currently defined: Success Busy No Service Refused Suggestion to add: "Invalid Service" Other Model Items discussed: Max_Task_Set_Size Presentation on Queue and Max_Task_Set_Size Proposal to dynamically change the Max_Task_Set_Size after a login. Proposed to add 2 new commands: Overview: Update Max_Task_Set_Size (MTSS) Target updates maximum number of re-orderable tasks by allocating/freeing its resources. Summary: Discussion initially postponed pending review of all Command related presentations. Follow-up discussion yielded the following results: Issue: When does the Target need to change it's MTSS. Issue: Can it shrink or grow the resources after Login? Consensus: Desirable feature. Issue: What is the mechanism to do this? Add a new Command or modify an existing command? Motions made and passed: "The MTSS be variable during the course of a Login, but be allocated per Connection". This means that resources allocated by one connection cannot be used by another. "To restrict the change to MTSS to happen at Connect and Disconnect". Requires a change to 4.3.1 in the "Model and Command Set" document. Clarification: The parameter to change the MTSS increases the number of tasks for a particular queue. "Create an unsigned parameter, Task_Slots, whose intended usage shall be restricted to the connect requests and responses." Kill Command, Abort Task Two methods of implementing a "Queue Kill" command. Receipt of command would terminate all Tasks associated with that Queue, terminate the connection, and reclaim any freed buffer space. Overview: Solution 1: Clean up the rest of the ORBs bound to the queue that has already terminated using completion status without execution. Solution 2: Make the initiator keeep the order of the ORBs that belong to the queue being terminated. This would apply to all ORBs related to the queue #0. Discussion: Difference in disconnect and Kill Queue proposal required new definitions. Disconnect - If the Initiator gets a disconnect does it immediately send a reply or does it clean up it's outstanding ORBs and then send the reply? Noted that Synchronous and Asynchronous have different usage model. Issues: When one end brings down the connection (gracefully), do we acknowledge the disconnect? Definitions: Synchronous disconnect command is sent on the queue for the connection and should not require special clean-up when closing the connection. Asynchronous disconnect is sent on queue 0 and require external synchronization to clean-up when closing the connection. Summary: The group should recommend that the disconnect is placed on the queue for the specific connection(synchronous). The disconnect placed on queue 0 (asynchronous) fulfills the kill queue requirement and requires a different encoding (connection params). The group decided to add a command called "ABORT_CONNECTION". 1212 Keywords and Features Group discussed keywords and brainstormed an initial list. Summary: Keywords noted in the ConfigROM issue 970514-007. Keyword to be added to the Config ROM doscument. Issues: Differences between keywords and attributes. Keywords allow for "rapid" discovery of devices that are of interest to the client. Attributes (features) would be used to provide more detailed information on the device. Once devices are identified by a keyword search, the attributes would be used to further refine the list to specific nodes. Do we provide a recommendation for separate Function and Attribute keywords, or do we just provide a list of words. Matched Request/Reply ORB and Commands vs. Actions Discussion which addressed concepts in Matched Request/Reply ORB and the "Commands vs. Actions" section of pwgpr43.pdf. Summary: All control functions in "data" stream (i.e., in buffers, not in ORB) ORB Commands I2T_Control T2I_Control I2T_Data T2I_Data Login Grants: Queue 0 n Task_Slots (minimum 1) (more at targets option?) Control: I -> T Queue an ORB T <- I Set a "please fetch control information" in status block, or Unsolicited Status block Control Functions: Connect Disconnect Kill Control Stream encode: Length Control Request Params Length Control Response Params Issue: Question as to why we need separate I2T and T2I since we have a direction bit in the ORB? This would reduce the commands to: Control and Data with the direction set in the ORB. Issue left open pending further work on proposal. Issues: Continue with concept in pwgpr43.pdf or idea put forth in this discussion. Spawned action item for Peter. Notify Initiator Mechanism Requires investigation. Spawned action item on Unsolicited Status is implementations. Connection uses string or ID Reversal of decision from Tucson. In Tucson we discussed using a 24 bit ID. IANA uses a string with limited ASCII. We will use a string in connect requests. Tag Bit Indicating Out Of Band data (OOB). Needs proposal. Spawned action item. Abort_Task_SET / TARGET_RESET Issues: How to be transparent to the application when an "ABORT_TASK_SET" or "TARGET_RESET" command is received? How does the device/connection recover from here? Summary: ABORT_TASK_SET Question was raised as to why someone would want to continue if this command is received. Greg LeClair explained that a typical use of ABORT_TASK_SET would be a execution timeout for an ORB. An initiator may try to submit the ORBs again or may return the buffers to the upper layer. RESOLUTION: This will be handled in the same was as BUS_RESET event. Buffers will be resubmitted with the same CDB and buffer content. TARGET_RESET Requires more investigation because the next command after a TARGET_RESET will cause a UNIT_ATTENTION condition. Open Issue: How to deal with the "TARGET_RESET" command? Update of issue from January 21st, 1998 Meeting in Maui, HI SBP-2 Model Model and Command Set Review: See document: pwgpr45.pdf Note: separate from Profile document - focused on Model and Command Set Review of changes: Issues: How are queue numbers assigned? Transport_Capabilites � Remove the Capabilities and Reply command. Remove Mode in the I2T_Connect. Clarify that determining the Service_ID string is beyond the scope of this standard. There may be an Informative annex that demonstrates how to do this. Disconnect � Commands and Replies shall go on the same queue. Review of an "Informative annex" by Peter Johansson - a work in progress. The document suggests a different encoding for the commands (actions). Summary: New encoding for actions using existing and new bits in the ORB and redefined action field A single, mixed management queue ORB status and unsolicited status can be used by the target to request T2I control ORBs Consensus that we should move in this direction with the document. Summary: Editor will await changes from Peter Johansson and roll them into the Model and Command set document before Miami mtg. Other Model Items discussed: CSR Message Request/Response Use to add Peer to Peer functionality to 1394 PWG profile (Target originated communication) Outside scope of SBP-2. Two levels of service identified: PC host to device (request/response) Device to device ("Login to me") Issues: Addresses issue of notifying the host that target device needs service. PC Software OS may or may not support. End of data indicator Issues: Do we have anyway to indicate the end of a data block or end of job? Usage: HTTP sends chunks of data with varying lengths. HTTP sends a chunk with a zero length that indicates the end of that job or block. Model for graceful disconnect Please review presentation "GraceDsc.pdf" Presentation on ideas of how the disconnect may work. Work in progress. Overview: The originator of a disconnect request places it on the queue that it controls. If the Target initiates the disconnect then it places the request on the T2I queue. If the Initiator initiates the request then it places it on the I2T queue. Issues: It was determined that it is necessary to develop state diagrams for this item to better understand the issues. Peter partially agreed to do the state diagrams as it applies to his work in progress proposal. Half Close Issue Please review presentation "HalfCls.pdf" Presentation on how a "half close" works with other transports and how we should handle this in 1394 PWG profile. This is the case where one side will no longer receive but may send. Summary: Motion was made and seconded to dismiss this capability as out of scope. Discussion led to a second motion to table the original motion. Discussion on table motion. Reason is to wait until we have more information. Would like to see a mapping of an API to Winsock. Need to justify a reason to have half closed in order to determine if we need to do implement it. The opinion is that this can be done at a higher layer and therefore does not need to be addressed in this standard. Spawned an action item for Socket to Transport command set mapping to assist the group in understanding weaknesses in the current model and command set. Tag Bit Please review presentation "Tag_and_EOM_bits.pdf" Presentation on how "out of band" data is handled in other transports. Summary: No issues noted. End of Message Indicator Three options proposed for handling the end of message. (not noted in Minutes) Presenters preferred method is to include an "EOM Indicator" with the last data packet or with a packet of zero length. Summary: Chair proposed that we wait until the Socket API mapping is produced to better understand the requirement. Open Issues Review Half closed Need concrete proposal in order to work on this. Abort Task set (closed) Target Reset Need to address. Greg L. will work with Mike Fenelon. Tag bit (Winsock) � API document Matched Request/Reply ORBs (San Diego) Closed. Use unsolicited status. Commands vs. Actions (San Diego) Peter will provide more on this. Disconnect (Maui). Closed Kill Queue � Closed. Became Abort Connection Closed T2I Communications. Will use Msg Request / Message Response. Needs to be rolled into the profile. Closed Result Codes. Suggestion to use a new code "Invalid Service" Included by "Unspecified Error" status. Closed Keywords Closed Update of issue from March 1st, 1999 Meeting in Miami, FL SBP-2 Model Model and Command Set Review: See document: pwgpr49.pdf Update on definitions (Specific changes not noted in minutes) Issues: Modify drawing on page 5 showing queue to task relationship. Should the target be responsible for checking the direction bit in ORBs that have a defined direction (I2T T2I mixed)? How long is "reasonable" for an ORB in the command queue to be completed? A target should complete queue 0 tasks "quickly." Do we need to define what "quickly" means? Peter made a suggestion that we should define a timeout like the Management ORB timeout timer. This timer is in 500ms increments with a max of 125 seconds. Clarification on page 5 section 5, last sentence. Change to "neither the initiator or target shall place more than one ORB on Queue 0." Need a better diagram to show control information flow, section 5.1 and figure 15 of IDT_r01.pdf. Section 5.1, page 7: How does the Target communicate the size of the buffer it needs? Change it to read something like "�should be big enough to �" Define a new result code that indicates "need larger buffer, no action taken" or something to that effect. Residual is defined as the: (amount of buffer space available ) - (amount of data transfer requested) Section 6.1.2 Return codes. Remove items: 3 Invalid Control ORB 4 Invalid Data ORB These errors can be covered by the Unspecified Error return status. Section 6.2.6 Remove result value: 6 Unknown Service_id_string Section 6.3 Error Reporting Precedence Currently: 1. SBP-2 errors 2. ORB command dependent errors Change to : 2. Completion Field 3. Result Values 4. Unknown or unspecified errors Section 7.1 and 7.1 - Disconnect is on a given queue so that it does not require a queue number. Abort goes on the command queue therefore it needs the queue number as a parameter. Other Model Items discussed: Sequence numbers Signature Proposal Proposal to use the Sequence Number field as a Signature field. This field would be used to identify and reconnect to an existing connection after a bus reset. This is outlined in the document IDT_r01.pdf. ORB History Proposal This proposal maintains a history log of ORB execution. Upon completion of an ORB (Status Response received) the history is discarded and completed. Will come up with a different term for the field other than Sequence Number. Summary: Spawned action item to integrate the two proposals. Disconnect API: Presentaton on how the Winsock 2 specification defines Disconnect. Discussion: Queue vs. connection Disconnect Issues involved in doing a Disconnect for uni-directional and bi-directional connections. Is the current approach broken? Review of the requirements for Disconnect: Efficient management of resource allocation and release. Simplicity Synchronization of the End of the Queue between T and I Shutdown API support: A. Send: Notify receiver that there is no more data to be sent. Queue is shutdown B. Receive:May need to notify sender that Queue is shutdown C. Both: Do both Send and Receive Shutdown: A. Send: Guaranteed data delivery B. Receive:Data delivery not guaranteed C. Both: see Send and Receive Abort a blocked queue Issues: Action Item: Need an implementation note that explains how to use the Notify Bit in both initiators and targets. Brian will make a motion at the next meeting that will change the spec to require that the Notify Bit be always set to '1'. This is the two week notification. A diagram was drawn for each of the shutdown process that indicated what should happen in each case of the shutdown. Peter will incorporate this into a document that describes these concepts. Half Close Issue From previous meeting Summary: Motion was made to untable the motion. Original Motion withdrawn. Accepted. Update of issue from April 13th, 1999 Meeting in New Orleans, LA SBP-2 Model Review of Open Issues and Action Items: Requested that we maintain a separate document on the web site that lists the closed and open issues. Noted in minutes to be at discretion of the WG chair. Open Issues Review Half closed Need concrete proposal in order to work on this. (closed) Abort Task set Will define in profile to deal with like a bus reset condition. (closed) Target Reset Need to address. Open Issue Zero max T2I data size closed since we removed the max T2I Closed Tag bit (Winsock) � API document Tag_and_EOM.pdf presentation Document IDT_R01.pdf Matched Request/Reply ORBs (San Diego) Closed. Use unsolicited status. Commands vs. Actions Issues updated in IDT_R01.pdf To be integrated into profile (Miami) Disconnect (Maui). Closed Kill Queue � Closed. Became Abort Connection Closed T2I Communications. Will use Msg Request / Message Response. Needs to be rolled into the profile. Closed Result Codes. Suggestion to use a new code "Invalid Service" Included by "Unspecified Error" status. Closed Keywords Closed Action Items Review: Model and Command Set Review: See document: pwgpr49.pdf Issues: Modify drawing on page 5 showing queue to task relationship. Should the target be responsible for checking the direction bit in ORBs that have a defined direction (I2T T2I mixed)? How long is "reasonable" for an ORB in the command queue to be completed? A target should complete queue 0 tasks "quickly." Do we need to define what "quickly" means? Peter made a suggestion that we should define a timeout like the Management ORB timeout timer. This timer is in 500ms increments with a max of 125 seconds. Sequence numbers Action Item: Peter will prepare a document that incorporates Shimura-sans' history concept with Peter's signature proposal. Not available at this time. Profile Document Need to review chapter 8 drawings for the target and initiator and then merge this with the IDT_Rx and PWGPR49 documents. Action Item: Alan and Peter will integrate these drawings and provide an update by the next meeting. Not available at this time. Review of IDT (Image Data Transfer) Document Reviewed document IDT_r01.pdf and determined areas that needed clarification. Action Item: Mike Fenelon will provide an example diagram for the use of the End_of_Message bit. Not available at this time. Target Reset Action Item: Reset Connection. Greg Shue will take a stab at defining the scope of this control function. Not available at this time. T2I and I2T data size vs. buffer size What the operation should be for datagram and stream operations. T bit and what "residual" data size will be indicated. Action Item: Peter will take the concepts from this discussion and incorporate them into the document. Not available at this time. Disconnect API: Action Item: Need an implementation note that explains how to use the Notify Bit in both initiators and targets. Brian will make a motion at the next meeting that will change the spec to require that the Notify Bit be always set to '1'. This is the two week notification. Discussion at this meeting Old Items Reviewed / Discussed: Disconnect API: Proposal for "Supplementary Control Function for Reliable Disconnect Across Bus Reset". Document filename is "DisconnReConfpre.pdf". Overview: Follow on to discussion on Sequence Numbers and Signature fields from last meeting. Provides a new control function, "Disconnect Confirmation". Issues: What to do if ACKs or NACKs get lost? Are there general and specific things that need to be addressed. Specifically what to do if the ACK is lost on the final ORB? (Disconnect) Disconnect � Target ORB � Nagasaka-san Proposal for a Disconnect command - "Bus Reset and Reconnection" Document filename is "proposal-99.03.19.pdf". Overview: Add a Tagged ORB parameter. Different way of detecting the last ORB than the signature approach. The Tagged ORB is a pointer. Issues: This can be simplified by changing the pointer to a signature. How is this different from the "Final Bit"? What does this solve that the Final bit does not? Buffer Size for T2I Data Transfer Overview: Discussion on Blocking/non-Blocking data streams. Issues: Socket in Blocking Mode (Initiator) What does the initiator expect? How does the target behave? Socket in non-Blocking mode (Initiator) What does the initiator expect? How does the target behave? Issues: Action Item � Brian to provide a mapping for all the entry points for all the PWG modes.
Back to the Top of the Page

Back to the Issues Page / Back to the Top of the Page

If you would like to contribute any input, contact Greg LeClair.
Last modified May.18.1999.