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 BASE-T 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 and auto-MDI correction in order to make sure a connection can always be formed.
Not necessarily true. What you say is true for those products whose ports become visible in the open marketplace. This leads to a distorted perception of things.
There are many, many ports sold that are embedded in commercial systems in such a way that they are not intended to be available to operate with other parties BASE-T systems. Others appear deeply embedded in systems where outside interoperability is not a desired feature (e.g. aviation, aerospace) . Nonetheless, these system designers get to reap the advantages of Ethernet systems components that are manufactured in very large volume.
This has a great deal to do with why the automotive folks came to us for their next-gen connectivity, even if they don't need several of the features we take for granted as being needed to succeed in the general marketplace.
Every modern PHY supports Autonegotiation and auto-MDI correction 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.
Autonegotiation is not optional for 1000BASE-T and higher speeds.
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.
But ports sales are orders of magnitude smaller than they are for BASE-T ports.
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 use case 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.
Which is why I am willing to NOT have a mandated connector for 10BASE-T1S.
That portion of the project was largely created to satisfy the needs of the auto industry.
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.
Compliance turns out to be highly overrated in my long experience. What customers are willing to pay for is interoperability.
Compliance is only the pissing contest that vendors get into when trying to resolve interoperability problems.
If there are no interoperability problems compliance never comes up.
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.
I vote for a single required connector for clause 146 and have the connector spec for clause 147 align to the other automotive TP clauses.
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.
IEEE Std 1588 Precision Time Protocol does profiles. It has so many that it is a mess (in my opinion)
I don't think this is the way we want to go.
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.
I disagree, see above.
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