| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I agree that our job in the standards is
not to define implementations, but to set interface specifications. I’ve
discussed this in the ad hocs but it looks as though it’s time to bring
it to the reflector. The issue here is whether the TP2 and
TP3 specs are set to enable 100m OM3 only or 150m OM3 and 250m OM4 fiber.
In order for the CDR in module to go the longer distance the TP2 and/or TP3
specifications need to be tightened. (otherwise vendors can put the
CDR in the module, and relax other module performance, still meet the 100m TP2
and TP3 specs and will only go 100m). It is possible to set the TP2 and TP3
specs in a generic manner that will achieve the longer reach. These
are the optical specs. The electrical specs on the module inputs
and outputs can be either 1 the
PMD service interface for optics, 2 the
PMD service interface for copper (may be the same or different to the optics
version, I think this is still a TBD), 3 XLAUI/CAUI. If people are using XLAUI/CAUI then a CDR
is very likely needed in the module. If people are using the PMD service
interface for optics then it is possible to either include the CDR in the module
or improve other aspects of a limiting part to achieve the TP2 and TP3 specs. If people are using the PMD service
interface for copper the host will include EDC and a linear module could meet
the TP2 and TP3 specs. IE by appropriate test methods and spec
setting it is possible to achieve the longer distance without picking an
implementation method. Note that this still leaves the question
of whether longer distance TP2 and TP3 specs should be the only normative specs;
there would be two sets of normative specs; or the longer distance specs would
be in an informative annex. From: John DAmbrosia
[mailto:jdambrosia@xxxxxxxxxxxxxxx] Brad, Thank you for bringing up these points. During the
course of this project, I have emphasized that we are developing an
architecture that should enable as many implementations as possible, and not
writing an implementation specification. You have hit the nail on the
head with your points. The base proposal for the BASE-SR physical layer
specifications is based on the jitter associated with a non-retimed interface
to achieve 100m. There has been general discussion that adding retimers to
a BASE-SR module would then extend reach. Per http://www.ieee802.org/3/ba/public/AdHoc/MMF-Reach/Comparisons_xr_01_0722.xls, and column
D (latchman_xr_01_0508), CDR’s on one side would extend the reach to 168m
and CDRs on both sides would be 208m (both #’s are based on OM3
fiber). So if we review the adopted architecture proposal, and
consider implementations for different reaches, what do we find? The thing is that we approved an architecture with the XLAUI
/ CAUI optional interface. This is a retimed interface. So it seems
to me that we have developed an architecture where either implementation using
the same PMD sublayer could be developed, i.e. a PPI (non-retimed interface) to
a module or a XLAUI / CAUI (retimed interface) to a module. Thinking about how to implement in the spec - The minimum
guaranteed interoperability would be 100m, which is in the current
specification. An informative annex could then go into engineered links
for 150 and 200m, based on the use of modules with either the PPI or the XLAUI
/ CAUI interfaces. Pardon the choice of words, but I think this would be
rather informative anyway, as the spec already enables both types of
implementations. Based on this, it would seem that the TF has been successful
in developing an architecture where implementations could be developed to
support either reach. Regards, John From: Brad Booth
[mailto:bbooth@xxxxxxxx] Dave, I agree. A 5% cost adder seems
reasonable for a 17% increase in broad market potential. I do wonder if part of the problem
is the compliance points TP0, TP1, TP1a, TP4, TP4a and TP5. In past
efforts such as 802.3z and 802.3ae, these compliance points have been left up
to MSAs and only TP2 and TP3 were of concern. Now the task force is
dealing with such issues as modules and the cost impact of various
implementations. IMHO, IEEE 802.3 was trying to avoid writing
implementation specifications and was focused on compliance
specifications. Could it be that these compliance points are causing the
task force some heartache because it results in an implementation
specification? Just food for thought... Thanks, Brad From:
Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx] The 20% cost premium applies to only one
of our proposed XR alternatives. According to the alternatives spreadsheet
(Comparisons_xr_01_0708.xls) the CDR option adds only 5% module cost premium
over the base proposal and provides reach of 168m to 251m (across the OM3/4,
one-sided/two-sided matrix). I’m struggling to keep up with the
conversation here – but I believe that the 5% alternative addresses the
same problem as the 20% alternative, right? On that assumption I will rephrase
Dan’s non-rhetorical question to address a 5% cost adder for 17% increase
in coverage: If I have the choice between: A) carry two product SKUs: 100m and 150m,
with 5% Bill of Material cost delta on the 150m product; or B) carry only the 150m product I would accept option B & use only the
150m module even though I know that most of my customers will use it at
<100m. By considering only the bill of material
of the module we are missing two aspects of the big picture on cost. 1) Carrying multiple
product SKUs through design, validation, manufacture, customer qualification,
customer confusion, etc. adds cost. Regardless of whether
802.3ba adds a second objective, if the module supplier base develops two
different module solutions for 100 & 150m, then the 100m solution will
carry an intangible cost burden and the desired 0% cost adder for 100m will not
be achieved anyway. 2) The module is not the
whole solution. The CDR module solution does not add cost to the host.
Thus a 5% increase in module cost is less than 5% increase in the total
cost of the switch plus modules. I appreciate that the task force is
learning from the history of 10GBASE-SR: that over-specifying the solution had
a long term cost impact. However, we should take away another
lesson from 10Gbit: that providing too many options confuses the
customers & slows adoption. I strongly urge the task force to provide
a single solution for parallel MMF. I believe that it’s worth a 5%
cost adder to the module to achieve that. I really have no personal (or commercial)
reason to prefer the CDR option. I’m just looking at the 5% figure
in the spreadsheet & wondering why this isn’t a no-brainer. Thanks for your time, Dave Chalupsky From: Hi Mike,
Assuming we make the decision that we want
to stick with the "standard" model at 100m to keep those customers we
would lose by adding cost, does the IEEE standardize a 150m solution or do we
let the market solve that problem on its own? This is not a rhetorical question, although
it might appear to be. Can someone provide any insight on the
sensitivity of the market to an additional cost of 20% for every 100m link to
satisfy the additional reach? If the market is insensitive to cost (on
this scale) then perhaps the additional reach is justified. If the market is
going to be sensitive to that differential cost, then the question falls back
to whether the IEEE wants to do a 150m spec or leave it to a market-defned
solution. Dan From: Mike
Dudek [mailto:Mike.Dudek@xxxxxxxx] Hi Dan Of course if we don’t increase the
cost of the basic Grade A model and have a Grade B version of the same part for
extra reach with the Grade B version being loaded with any additional costs of
handling two product codes and any additional testing, then we shouldn’t
lose any customers. Regards Mike Dudek PMTS Standards & Technology JDS Uniphase CO 80027 Tel 303 530 3189 x7533. mike.dudek@xxxxxxxx From: Let me re-state one word of that
message. From: Hi Steve, Yes that helped a lot. I hope the others
on the list are not irritated by my request for repetition of the data. Given the data, it truly is a challenging
issue. I see a 20% premium for a 17% increase in coverage. This means the confidence in the numbers
is exceptionally important and assuming they are accurate, a judgement call by
the committee on whether or not a 17% increase in port coverage justifies the
20% increase in cost. This is important because if you increase
the *COST* of a solution by 20%, you may decrease the
number of customers who are willing to buy it by more than 20%. Thus, in the
overall mix, it might turn out to satisfy less customers overall. Its a pretty challenging judgement call
IMHO. Thanks for providing the data. Dan |