Hi Folks,
The topic of this thread really seems to be:
What to do about multidrop/point-to-multipoint?
I feel like I’ve seen clear information about technical and economic feasibility for point to point, but not so much (particularly when it comes to powering) for multidrop/point
to multipoint.
I think that given the material we have seen, there is clearly a viable market for point to point, and there may be one for multidrop/point to multipoint if we can work
out how to build it cost effectively.
My preference is to head into the Task Force with the goal of doing (at least) point to point, and at the same time investigate how to solve the multidrop/point to multipoint
topology without resorting to 3 port switches at every junction.
While I can see where Pat is going with the “and possibly shared media operation” and “Consider support for shared media” language, I’m not sure that it really adds
anything to our agreement of deliverables with 802.3 (which is what the objectives are).
As written, #10 says point to point for the 1 km link segment, and #9 doesn’t specify for the 15 m link segment. It seems like both P2P and P2MP are within the scope
for 15 m link segment which means I would expect to see presentations to the task force to work towards technical baselines for both.
If it turns out that we find a way to get P2PM done, then we are OK. If it proves problematic, we can drop it without having an issue with our objectives.
Regards
Peter
_______________________________________________
Peter Jones Cisco Systems
Principal Engineer 560 McCarthy Blvd.
Campus Switching S/W Milpitas, CA, 95035 USA
Wrk: +1 408 525 6952 Mob: +1 408 315 8024
Email: petejone at cisco.com
Twitter: @petergjones
LinkedIn: /in/petergjones
_______________________________________________
From: Pat Thaler [mailto:000006d722d423ba-dmarc-request@xxxxxxxx]
Sent: Friday, October 28, 2016 2:46 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Objectives - things we seem to have consensus on
I think the difficulty in separating the 15 PHY objective into two objectives is that it isn't clear that it will be two PHYs. It is possible that the same PHY would be used for both point to point and P2MP/bus.
We have had groups in the past with an objective to consider including a feature in their standard - i.e. at the time we started the project, we felt more work was needed to decide whether to include that feature; that the feature was a
nice to have but not a requirement.
One way of making that explicit would be to have objective 9 be:
Define the performance characteristics of a link segment and at least one PHY to support point-to-point operation and possibly shared media operation over this link segment with single twisted pair supporting
up to four inline connectors using balanced cabling for at least 15 m reach
Consider support for shared media operation at distances up to 15 m.
On Fri, Oct 28, 2016 at 12:59 PM, Geoff Thompson <thompson@xxxxxxxx> wrote:
George-
My thought was based on the belief that multi-hop and/or P2MP are a very different beast
and thus should have distinctly different objectives.
There are two reasons, because there are two wording differences:
- “at
least one phy” (15m) vs. “a phy”(1 km): I don’t want to preclude the 1km phy from working on the 15m link segment, and want to make it clear we could end up with 2 phys that work on the 15m segment, but only one for the 1km link segment.
- Omitting
“point-to-point” on the 15m – While I believe we have consensus that the 1km link is not multi-drop, at this point we have had much discussion and reason to believe that a multi-drop 15m phy would be useful as well as meet the BMP and Economic feasibility
CSDs. Our CSDs and PAR as written do not preclude this. We need work to specify the multi-drop scenario, and, I believe that requires technical decisions that are beyond the scope of what a study group should be doing (e.g., choosing media access approach).
I could live with the addition of “point-to-point” on the 15m link, but wanted to start general – let’s see what the consensus in the study group is.
My personal belief is that at this point in the objective we can be general, and make room for an additional objective for multi-drop (not multi-hop, which would involve phy
termination) links should it be proven out with technical decisions, perhaps refining the wording of this objective at that time.
Perhaps you could explain why it would be an error to leave the objective general? (or is it not an error, but a malformed piece of beef? (a ‘misteak’)
(FYI, I’m going to be offline now for a while… don’t read anything into my silence)
Thanks for jumping in, Jeff.
Why is your wording on your draft 9 and 10 different?
If is because you want to leave things open for multi-hop
I believe that would be a misteak.
Point-to-point links should have separate statements from multi-hop links.
I’ve been preparing a presentation to close our objectives, and from the ad hoc discussion, we seem to have consensus on the following objectives. (another few email threads
will discuss the ones we need to work).
Please reply whether you have issues with consensus on these, and with some explanation of the concern, or proposed alternative wording. Please reference the number of the
objective in your comment. These are NOT intended to be all the objectives, just the ones that I have heard general consensus on in the ad hoc. This way we can have a more efficient meeting in San Antonio.
(the adopted objectives are #1 through 8)
- Define the performance characteristics of a link segment and at least one PHY to support operation over this link segment with single twisted
pair supporting up to four inline connectors using balanced cabling for at least 15 m reach.
- Define the performance characteristics of a link segment and a PHY to support point-to-point operation over this link segment with single twisted
pair supporting up to 10 inline connectors using balanced cabling for at least 1 km reach
- Do not preclude working within an Intrinsically Safe device and system as defined in IEC 60079
- Do not preclude the ability to survive automotive and industrial fault conditions (e.g. shorts, over voltage, EMC, ISO16750).
- Support fast-startup operation using predetermined configurations which enables the time from power_on**=FALSE to a state capable of transmitting
and receiving valid data to be less than 100ms.
- Support voltage and current levels for the automotive and industrial environments.
10 Mb/s Single Twisted Pair Ethernet Study Group
Experts in Advanced PHYsical Communications