Multilane_Connector

Charles E. Brill cebrill at ix.netcom.com
Wed Aug 21 05:44:57 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Charles E. Brill" <cebrill at ix.netcom.com>
*
Dal:  We are in agreement to get this defined. Bob mentioned about September
getting together to resolve it. Can he let us know where and when this
meeting is  asap? We are presently making reservations for various Sept
meetings. Chuck Brill.

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf
> Of Dal Allan
> Sent: Monday, August 19, 2002 1:30 AM
> To: t10 at t10.org
> Subject: Multilane_Connector
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Dal Allan" <endlcom at acm.org>
> *
> Howdy all,
>
> Bob Thornton asked me to forward this to T10, so enjoy your reading.
>
> Dal
>
> ------------------------------------
>
> Respond to: bthornton at fcai.fujitsu.com
>
>   Subject:  SFF SSWG re: Keying for 4-lane Copper I/O Connector
>
> During the SFF SSWG meeting at T11, there was discussion
> concerning the
> requirement (or lack thereof) for various keying of the 4-lane that
> would differentiate the interface between the following standards:
>
>   10G Fiber Channel - FC-PI-2
>   Serial Attached SCSI (SAS)
>   Serial Attached ATA2
>   10G Ethernet
>
> The concern has been voiced by some that keying was preferred, if not
> required, to prevent the possibility of "smoking" a machine should the
> I/O connector be plugged into the incorrect port. When
> discussed at the
> SSWG meeting, and at T11.2 Copper, there was head scratching
> as to what
> was in these standards that would allow for the "smoking" gun, so to
> speak.  As these systems are all based on some form of XAUI, it was
> thought that this was not a relevant concern. Please note that we are
> not referencing InfiniBand, as the selected copper interface provides
> sufficient keying to insure that the interfaces are not intermatable
>
> Alvin Cox of Seagate expressed the following:
> If every interface required AC coupling, there would not be a problem
> unless voltage levels go too high. The thing we ran across during our
> discussion within the SAS group is that not every interface
> requires AC
> coupling on both transmitter and receiver. This is where we may
> encounter a smoke situation. There is also the concerns regarding SATA
> external cables. The electrical requirements have not been defined yet
> for this interface and I cannot predict what the outcome will be (nor
> can I share the information at this time). A table of all the
> interface
> characteristics would be a great starting point. It is definitely a
> necessary one.
>
> I have been chartered (I did not get out of the meeting quick
> enough) to
> chair an meeting where we can define these issues that are relevant
> between these standards bodies to resolve this issue. I would like to
> propose a possible meeting (schedule not defined - looking at
> September)
> for any and all interested parties to meet with the goal to develop a
> chart defining some of the potential differences (or maybe find that
> there are no real differences) of these standards concerning cable
> interconnect issues.
>
> I feel that this issue can be (hopefully) quickly resolved to the
> benefit off all interested parties in a quick and timely fashion (you
> can tell I have never chaired one of these meeting).
>
> I am traveling out of the country next week, so will be unable to
> respond to any questions until the week of August 26th.
>
> Regards
>
> Bob
>
>   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>      The following response came from Bill Ham
>      after Bob posted to the T11.2 reflector.
>
> Hi physical folks,
>
> As noted in the T11.2 meetings the risk of smoking something is not
> mitigated by ac coupling except in the unusual case where a high d.c.
> level exists.  The main risks of smoking something come from transient
> events that are just as likely between interfaces for the
> same transport
> as they are between interfaces of different transports.  The
> T11.2 group
> took the position that it does NOT want keying as a standard
> requirement
> because it provides:
>
>    * a de facto n-furcation* of the volumes for any one transport with
>      resulting loss of leverage
>    * very significant complexity in the configuration, ordering and
>      servicing dimensions where multiple transports are supported
>    * false belief that keying will prevent connector engagement to a
>      determined individual who intends to make that stubborn connector
>      mate no matter what
>    * false belief that keying significantly mitigates the risk of
>      damaging something (it acutally increases the risk that
> both parts
>      of the connector, including the very expensive to
> replace bulkhead
>      connector, will be damaged due to attempted forced matings)
>
> Not having keying in the standard still leaves open the option for
> anyone who wishes to have a closed system to have whatever keying they
> desire.
>
> There were NO discenting votes in the T11.2 group on the point.  So if
> parts of the industry decide that they want their very own key, the
> Fibre Channel key will be the null key (i.e. none) - assuming
> of course
> that folks in T11.2 do not change their mind.
>
> *n-furcation is where the total market is divided by n; the
> most common
> of which is bi-furcation where n = 2.
>
> Cheers, Bill
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list