Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_10SPE] [EXTERNAL] Re: [802.3_10SPE] Proposed response to MDI connector comment r02-14



Hi all,

I've been following this discussion and a lot of very valid points are being made.

Like many, I believe that in order to be successful this single-pair standard needs
to be defined such that
a) systems can physically be connected (this implies a mandated connector)
b) after connection a link can be formed (this implies that there is always a 
functional PHY mode between any two devices)

Classic copper Ethernet has both of these properties, SPE does not.
In BASE-T, the  8P8C connector is nearly always used, and ports tend to support slower
link speeds in order to make sure a connection can always be formed.
Every modern PHY supports Autonegotiation to avoid the pain of manually configuring
a link.

I'm not 100% sure, but I don't think every BASE-T Clause actually mandates a
connector. Some for sure do, but not all. Yet the market overwhelmingly chose 
a single connector.
Autonegotiation is optional, but always implemented because not having it is such a pain.

Because this flavor of Ethernet is intended to be used by laymen, a combination of
vendor common sense, good 802.3 requirements, and market forces have led to a
successful set of standards.

I learned that both the optical Ethernets and backplane do not mandate specific
connectors. Yet, both of these are also successful standards.
The difference is that these are intended for a different kind of user and application.
Backplane Ethernet is mostly used within a system of a single vendor.
Optical links are installed by professionals and are not often changed or manipulated.
For those intended uses mandating a connector would have been a bad thing, it only
would have gotten in the way.

The two pure Automotive Ethernets (1000BASE-T1 and 100BASE-T1) are a bit like
backplane Ethernet. The intended usecase was use of data links within one vendor's
large system (the car). The need for device interoperability here was minimal, what was
really needed was PHY interoperability. As such it makes sense that those clauses
only specified what was needed for their intended use.

I've come to the realization that 10BASE-T1 fits in none of these categories.
It belongs in all of them.

For some, such as myself, we are looking for a single-pair Ethernet that behaves
like 4-pair Ethernet: with device to device interoperability.
But others are clearly looking for interoperability at a lower level
in the system: only PHY to PHY interop is needed within an (engineered) system.
A lot of the requirements that make device to device interoperability possible, would
be serious hamper to those usecases.

A significant amount of discussion in the CG group can be traced back to these
two different levels of interoperability.

Geoff points out that these are voluntary standards. Thus it is possible to only
implement the parts of the standard that a particular application requires.
Don't want to use the mandated connector ? Fine, then don't.
Only want to support long-range, half-duplex in a funny mode ? Fine, go for it.

It isn't that simple though. In order to claim "compliant to 802.3cg", the device
actually needs to comply with all the requirements. If a device opts out of one,
then it instantly can't make any claim at all anymore.
Also, if partial compliance becomes widespread, there is no guarantee of interoperability
at any level anymore.

I think we can satisfy the needs of both of these types of products.
Roughly the idea is this:
- a base Clause X has all the requirements needed for PHY to PHY interoperability.
This excludes device level requirements like connectors and specifying what PHY modes
need to be present. 

- another Clause Y has the device to device interoperability requirements.
This will specify what connector is to be used and what permutations of options
are permitted, such that any two devices always 'work'. Compliance to Clause X
is obviously a requirement in Clause Y.

Clause 146 and 147 right now float between these two levels.

This is similar to an "application profile" methodology that is used in other 
standards bodies. People have pointed out to me that 802.3 "doesn't do this".

Well... given that we are on new ground (specifying Ethernet for new kinds of
applications) we may need to revisit that.
I don't think 802.3 is the place to create profiles for a bucketload of niche applications,
but I do think it is in our purview to create a device-to-device requirements Clause 
that ensures interoperability _for general use_ in the same way we enjoy it for BASE-T Ethernet.

I am not suggesting major new work for 802.3cg.

However, I do want to explore this for the new Multidrop Enhancements project
that is just starting. My hope is that we can create a system-level interopability 
standard around multidrop SPE. With power.

Coming back to the comment. Not mandating a connector, or mandating a connector 
are both reasonable things to do for 802.3cg at this point.
Given that large amount of people only interested in PHY to PHY interoperability,
I think it best not the mandate a connector.

For 802.3cg to point to TWO different connectors in the current fashion runs a 
high risk of market confusion and those statements later getting in the way of
other standards aiming for device to device interoperability.
Please don't do this. It's guaranteed to complicate things for us in the Multidrop 
project.

Kind regards,

Lennart Yseboodt


On Wed, 2019-08-28 at 13:45 -0700, Geoff Thompson wrote:
Michal-

I believe that you truly misunderstand the discussion.
What we formulate are VOLUNTARY standards.
When you do an implementation of something that is a voluntary standard you can implement or not implement any portion of it that you want to.
However, when you do that you as a vendor take responsibility for fully specifying the portion where you deviated AND you take on the responsibility for creating the environment for test equipment and interoperability testing.

That is a set of responsibilities that is very reasonably taken on by automotive manufacturing entities either separately or within their trade organizations.  That along with lots of other well established requirements for connectors within the automotive environment made it appropriate for us to leave the spec of the physical connector to the auto folks.

However it is NOT a set of responsibilities that contributes to broad market success when the products (PHY equipped DTEs and cabling elements) are marketed to broad market communities as will be the case for 10BASE-T1L.  They want products that can be plugged together under a very simple set of rules and just work.  They work because we have guaranteed the operation of the full end-to-end system within the standard in pluggable off-the-shelf parts.  It has been the experience of the long term membership of 802.3 that a specific physical connector is a key element of those simple rules.

If you want to produce product with screw terminals then go for it.  If that is enough of a market advantage then that will become well known and may even take over the market over the long haul.

For the market to meet its potential, I believe a physical connector included in the standard, one who's presence shows up in the PICS PRO FORMA in the standard and in the product PICS, is necessary.

Best regards,

Geoff

Geoffrey O. Thompson, Life Senior Member
GraCaSI Standards Advisors
Mountain View, CA 94043-5286




To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1