| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Arvindh – you need to understand what 802.3 objectives are. Usually they are simple bullet points, not paragraphs with lots of caveats. They generally aren’t an ordered list. You don’t need caveats, and detail should be light - we aren’t writing the standard here. You don’t say How you’re going to do things in the objectives – you say What the standard is going to achieve. For
example, PLCA was never actually an objective in itself. A multidrop PHY for automotive & industrial network environments was the objective, along with the speed (10 Mbps at the MAC/PLS service interface), reach, and rate. The objectives are our commitment as a task force (when we become one) to the members of the working group on the minimum we are going to address. For example, for a PHY they are bit rate, error rate, reach
and medium. They need to be voted on by the members of the working group – so they shouldn’t be too deep inside the development.
They need to be at the level where when a working group member outside of the task force reads the standard, and can then make a judgement and base a vote on it – Voting could be on the WG ballot draft (whether
it met the objectives), or even as simple as whether we are ‘technically complete’ so that we can us proceed to WG ballot. In short, restrictions and caveats are assumed. A “PHY project” objectives may not be a good example for us, although we can use some of 802.3da as a model. 802.3da had a number of PHY objectives but also had: Specify an optional PLCA node ID allocation method And Support optional Time Synchronization Service Interface (TSSI). These are high-level, don’t say how we are going to do it, or even what the caveats are on usage. Another good example to look at would be the 802.3dt (Ethernet Metadata Services) objectives. They have a pretty high level project which interacts with things outside our scope, similar to EPLCA. Their
key functional objective is in one line: “ Define optional per-packet and packet-independent metadata services and associated modifications to the physical layers using the:” (and then with a list of the supported PCS’s intended). Regarding PHY support, that is still needed (it could be replaced with a more detailed statement about the Clause 22 MII, as in 802.3-2022, but that’s not really what we are aiming at…). Consider that you
are modifying the RS (which is PLCA). That includes the MII and interface to the PHY. If we were, for example, to invent a new MII encoding to be used, the existing PHY clauses would not understand how to encode that. We wouldn’t be compatible with the PHYs
as specified. Therefore, I think we need the statement about compatibility with the PHYs. Backward compatibility with CSMA/CD and PLCA is with regards to the MAC and to the other nodes on the mixing segment. Compatibility with the PHYs is on the local station, between the RS and the PHY. It’s
just a different thing. Again, I hope this helps, but frankly, you’re overcomplicating this – and looking at what is needed here, and has been done, is not only useful, it’s an essential first step. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Subramaniam Aravindhan <Subramaniam.Aravindhan@xxxxxxxxxxxx>
Hi Yong, and all, One recommendation to list the EPLCA first and backward compatibility later in the list.
Since we are supporting backward compatibility with CSMA/CD and PLCA, there is no explicit need to specify “Clause 147 & 188 multidrop PHYs” now. If we are committing to have changes only in 148 and no changes in 147 and 188, then we
could word it as “Only changes in Clause 148 and no changes in Clause 147 and Clause 188”. Thx, From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
I’m starting this as a new thread so people can keep it clear on the discussion. Regarding the objectives, I think at least Arvind and I agree that we need some clarification. Support interoperability with Clause 147 & 188 multidrop PHYs: I think that in light of the 802.3 definition of PHY, rather than the “chip” definition of PHY (which can be different for any implementer) “Support interoperability with Clause 147
& 188 multidrop PHYs” is OK. PHY means the PCS & PMA in IEEE Std 802.3, and that’s the audience – the working group. However, in the other basic objectives, we have some work to do: Preserve PLCA method: I agree we need something better than “Preserve PLCA method” Objectives need to be clear as to what we mean. There are a variety of meanings I could take from this. Less is more
in objectives – we don’t want to write how the spec will come out, but looking at what you have, I think we mean:
I suspect that we agree that this means something like your Backward compatible with PLCA; but EPLCA latency predictability will not be guaranteed… because interoperability doesn’t
mean the benefits of the enhanced technique are maintained. Most understand that performance goes to the lowest level… DPLCA: I think we need to discuss D-PLCA. I would suggest:
Given that D-PLCA can have a set of statically assigned ID’s we ought to be able to set up a working performance regime which doesn’t completely fail when E-PLCA is enabled on some nodes and D-PLCA
nodes are on the mixing segment. Whether we can come up with a way to preserve E-PLCA benefits with D-PLCA active is an item for work. Not sure we need to decide that now, but we shouldn’t have the network crash if you have both, and an objective to “Preserve
interoperability” does that. Specify PLCA selection service client to be used by upper layer: I think we need a little wordsmithing here. I believe we specify a client interface (primitives) to communicate priorities. This way implementers, and specifications
like 802.1 can control the mechanisms of PLCA to do this. We haven’t defined what the client actually is, and the innards are probably out of scope for IEEE Std 802.3. We also can’t define who uses it – that is above the scope of 802.3 (we can give them
the tools, but we can’t make them use them). Hence, I’d suggest we focus on the interfaces to parts that are actually in 802.3:
When we know more about the PLCA priority service client we might be able to say more here. It might be best to wait a little on this objective. -george To unsubscribe from the STDS-802-3-EPLCA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 |