| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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- 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 |