SBP-2 Extended Reconnect Interval proposal
John Nels Fuller
jfuller at microsoft.com
Thu Feb 19 11:26:15 PST 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* John Nels Fuller <jfuller at MICROSOFT.com>
I like this suggestion. I don't know if we can accommodate it in the ballot
review process, but there was a specific ballot comment about the reconnect
time-out so maybe it can be addressed.
> -----Original Message-----
> From: Greg Shue [SMTP:gregs at sdd.hp.com]
> Sent: Wednesday, February 18, 1998 4:43 PM
> To: t10 at Symbios.COM
> Cc: gregs at sdd.hp.com
> Subject: SBP-2 Extended Reconnect Interval proposal
> Hi all,
> I have been working with the PWG 1394 group in trying to figure
> out whether or not SBP-2 could/should/would be used for a standard
> printing transport protocol. During this work, we recognized the
> desire for access control (i.e. logins) to be maintained across
> transient link interruptions. These interruptions include a
> person disconnecting and reconnecting the cable. In trying to
> address this, I recognized that this is probably a SBP-2 level
> issue. What follows is a proposal for extending SBP-2 to provide
> an extended reconnect interval for asynchronous-only connections.
> I know it's very late in the standardization process.
> I feel the feature is general enough that I at least want to
> hear your comments.
> Proposed extension of SBP-2 for
> Programmable reconnect interval proposal for retained access
> control across transient link interruptions
> The SBP-2 proposal 0.3a currently has a reconnect interval
> fixed at one second. This may be sufficient for resumption of
> access control following a Serial Bus reset where neither the
> initiator, target, nor bus disappeared from the topology.
> Unfortunately it does not address the following situations:
> - the bus is inadvertantly configured in a loop (causing the
> entire bus to disappear)
> - the cable is disconnected along the path between initiator
> and target, and subsequently reconnected.
> (e.g. a child disconnects a cable in a home-office
> environment while a 1394 printer is in the middle of an
> hour-long print job.)
> These cases typify transient human interaction with the bus
> (which extend for longer than one second) for which access
> control needs to be retained. Though it is entirely possible
> to build an additional layer of access control on top of the
> SBP-2 protocol, this seems to be much more efficiently
> accomplished by a general extension of the reconnect policy.
> Proposed changes to SBP-2, Revision 3a, dated January 23, 1998:
> Section 3.1.2 Glossary:
> Add the following definition.
> transient link interruption: An interval long enough to
> allow a cable disconnect and reconnect to be performed by
> a human, yet short with respect to an interface access
> Section 18.104.22.168 Login ORB:
> The ORB diagram shall be changed such that the least
> significant 3 bits of the _reserved_ field are labeled as
> Beneath the paragraph describing the _exclusive_ bit, add the
> following text:
> The rcon_to field shall specify, as an enumeration, the
> maximum time a target shall allow for this initiator to
> complete a reconnection before releasing access to the
> interface. The supported values are enumerated in the
> table below. A one-second timeout is required for logins
> associated with a Create Stream ORB.
> Table X - Reconnect Timeout Values
> rcon_to value reconnect timeout (seconds)
> 0 1
> 1 5
> 2 10
> 3 30
> 4 60
> 5 120
> 6-7 reserved for future standardization
> Section 22.214.171.124 Query logins ORB:
> The indented NOTE shall be changed to:
> NOTE - A _node_ID_ value of FFFF(16) may be observed only during
> the reconnect interval programmed by the associated initiator.
> After this time the target performs an automatic logout of this
> initiator if it has not reconnected.
> Section 7.4.8 Logical_Unit_Characteristics entry:
> The Logical_Unit_Characteristics entry format diagram shall
> be changed such that the least significant 3 bits of the
> _reserved_ field are labeled as "rcon".
> The following paragraph shall be inserted before the one
> describing the _mgt_ORB_timeout_ field:
> The _max_rcon_to_ field (abbreviated as _rcon_ in the
> figure above) specifies the highest enumerated value
> supported by this implementation for a reconnect interval.
> The target shall support all lower enumerated values beneath
> what is specified in this field. The values shall match
> those specified for the _rcon_to_ field in section 126.96.36.199.
> All implementations shall support a value of zero. If this
> entry is missing, the enumerated value of zero shall be
> Section 8.1 Access protocols
> The end of the first paragraph shall be change to read
> "access rights across a Serial Bus reset or transient link
> The first bulletted paragraph shall have "a reconnect timeout
> vairable," inserted before "the base addresses".
> The thired bulletted paragraph shall replace "one second" with
> "the reconnect interval".
> Section 8.2.1 Login
> Paragraph e) shall be changed from "the _lun_ and _status_FIFO_
> fields" to read "the _lun_, rcon_to, and _status_FIFO_ fields"
> Section 8.3 Reconnection
> Paragraph 2 shall be replaced with:
> Subsequent to a bus reset, the target shall retain
> sufficient information to permit an initiator to reconnect
> its login ID (and, implicitly, any associated stream ID's).
> After the programmed reconnect interval, the target shall
> perform an implicit logout of the expired login ID and
> associted stream ID's if a successful reconnection has
> not been established.
> Following NOTE shall be replaced with:
> NOTE - A one second timeout shall be required for
> interfaces which provide isochronous stream control. This
> interval is to permit initiators to reallocate isochronous
> channels and bandwidth and to reestablish isochronous
> connections. Interfaces which do not provide isochronous
> stream control may support longer reconnect intervals in order
> to provide transient link interruption tollerance.
> NOTE - The reconnection time-out commences when the target
> observes the first subaction gap subsequent to a bus reset.
> If a bus reset occurs before the time-out expires, the
> timer is zeroed then resetarted upon detection of a
> subaction gap.
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs at sdd.hp.com
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10