SBP-2 Extended Reconnect Interval proposal

John Nels Fuller jfuller at
Thu Feb 19 11:26:15 PST 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* John Nels Fuller <jfuller at>
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]
> Sent:	Wednesday, February 18, 1998 4:43 PM
> To:	t10 at Symbios.COM
> Cc:	gregs at
> 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
> Purpose:
>   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
> 	session.
>   Section Login ORB:
>     The ORB diagram shall be changed such that the least
>     significant 3 bits of the _reserved_ field are labeled as
>     "rcon_to".
>     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 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
>       All implementations shall support a value of zero.  If this
>       entry is missing, the enumerated value of zero shall be
>       assumed.
>   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
>     interruption."
>     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
> ----------------------------------------------------------------
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list