Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Yes, What I meant by a new clause is to come up with the
protocol to support at speed exchange, rather than opening up Clause 37 and modifying it. From: Brad Booth
[mailto:Brad_Booth@xxxxxxxx] Velu, That’s the concept behind using sequence ordered sets. The
protocol is already specified and would only need minimal modifications to
support “at speed” exchanges. Cheers, From: Velu Pillai
[mailto:vpillai@xxxxxxxxxxxx] Hi Arthur, CL37 is a 8b10b code-word based page exchange, hence using it for
next generation optical PHYs is not possible. We can come up with a new clause to do “at speed”
auto-negotiation. In back-plane it will be used after the training sequence to
exchange abilities and request for next generation PHYs. Clause 73 will
classify the PHY and this new clause will handle the advanced abilities. And in
Optical PHYs, this will act as the primary auto-negotiation. This way a common negotiation
Clause can exist between the Back-plane/twinax and Optical PHYs. Regards, Velu
Pillai From: Arthur Marris
[mailto:arthurm@xxxxxxxxxxx] Brad, Let me make a few comments. For 802.3bj it is necessary to use Clause 73 for
auto-negotiation because Clause 73 already supports port types for four-lane
twinax and back-plane. If new 100G port types are being added for these media,
they need to be included in Clause 73. Clause 73 also gives you FEC negotiation
for free. Clause 73 clearly does not work over optical media. You can use ordered sets for exchanging ability and
requests, but this only works if both sides of the link are running at the same
speed and the error ratio is not too bad. For next generation optics you are
going to need to decide whether you need to negotiate speed in addition to
determining FEC operation (for example you might want to negotiate between
40GBASE-SR4 and 100GBASE-SR4). If you do decide to negotiate speed you could
consider re-using Clause 37 for auto-negotiation (which operates at a 1.25G data-rate). If you are not negotiating speed but are just
concerned about bit errors, then the task being performed is really link
training rather than ability resolution. Arthur. From: Brad Booth [mailto:Brad_Booth@xxxxxxxx] Stephen, It depends on the FEC
protocol adopted, implementation requirement, and the associated latency. The
discussion got started around the idea of using Clause 73 AN for FEC ability
exchange in the optical domain. Considering we’re still
in the study group phase, some of those questions cannot be answered as we have
not adopted an FEC proposal. If an exchange protocol is required, then IMHO the
use of sequence ordered sets would be preferred over creating of a new autoneg
protocol. Cheers, |