I agree that
John’s email outlines
the basic options for the MAC; however, I have some questions.
If the
Option (B) MAC isn’t 10G
based, then obviously the development of a new MAC is required.
However, even
if the MAC is 10G based, would there still be any changes required
necessitating a new 10G MAC design?
Does Option
(A) preclude the use of
multiple 10G MACs working together? (I think not, but I’d like others’
thoughts.)
Does Option
(A) preclude including
features which allow for less than all of the HSSG “lanes” working?
(I think not, but I’d like others’ thoughts.)
Does Option
(A) require that the MAC is
implemented in a single chip (whereas Option (B) does not)? (I think
not, but I’d
like others’ thoughts.)
There
definitely is a sense of justified pride
by the long time members regarding the fact that (unlike Fiber
Channel), each
new step in Ethernet was a large step which avoided lots of small
increments which
still required significant product re-development / inefficient
investment.
I am
concerned that the soft-scaling being
considered here will mean:
(1)
Different System Vendors will choose
different scale factors and won’t actually be able to talk to each
other as
efficiently as they talk to their own boxes. E.g. is Vendor A
implements
40G and Vendor B implements 100G… they would talk to each other at 40G
but this creates a disincentive to cross vendor boundaries since there
is an
expensive 100G port being under utilized at 40G.
(2) We have
taken the progress for certain
steps of the out of the standards process, but allowed for Vendors to
make the
small incremental steps (e.g. multiple factors of 2x)… a Vendor
starting
with a 40G implementation can go to 80G then 160G. Since 100G will
undoubtedly be hard just as 1G and 10G were hard, we have created an
incentive
for some to take the easier step now especially if it fits better into
their existing
system capacity. Thus we will share the same fate as Fiber Channel in
terms of cycle of investment.
Does Option
(A) have to operate at exactly
the traditionally 10x? Is 80G out of the question? It’s less
than 1dB difference, is a 2^n factor making certain issues easier, and
would
allow for coinciding with SONET/SDH speeds more often in the future.
While this
conversation thread is focused
on the MAC, it seems to have neglected to consider that vendors will
have to
make PHY/PMDs that work with these MAC options. When people have voice
support for Option (B) are they also suggesting that they support a
Scalable
PHY/PMD?
I can
understand why the MAC should be
scalable and how that can save development costs / investment; however,
making
a Scalable PHY/PMD would seem to me to mean increased PHY/PMD
development
costs, lots of different “flavors” of PHYs to be developed, not
volume behind any single “flavor”, and worse unit economics…likely
worse than linear scaling…e.g. worse than 10x$$ for 10xBW.
Does Option
(B) for the MAC preclude a single
fixed PHY/PMD implementation? (I think not, but I’d like others’
thoughts.)
Is a
Scalable PHY/PMD desirable? (I think
not, but I’d like others’ thoughts.)
I certainly
want to re-use 10G MACs, if
possible, to improve the economics for 10G and reduce the new
investment required
for HSSG. There are likely some silicon or system vendors working on
Quad
10G MACs, etc. Using a Scalable MAC approach will allow that density
improvement to be utilized for HSSG as well.
However, I
think it would be a huge
mistake (particularly for the short distance / datacenter / enterprise
applications)
to believe that allowing freedom in the scaling value of N would
somehow make the
PHY/PMD situation better. It would not be good for PHY/PMD developers,
nor for customer interoperability / multi-vendor internetworking. We
certainly have a responsibility to consider economic dynamics that will
be
created the by features of the standard we choose to implement.
-Roger
Thank you for a very
succinct summary of the two proposals.
Without repeating any
arguments, I am strongly in
favor of a scalable approach - proposal B
(which should continue
another tradition - a tradition
of successful implementation)
Best
Regards,
Yakov
Belopolsky
Manager, Research &
Development
Bel Stewart Connector
ybelopolsky@xxxxxxxxxxx
Tel. 717-227-7837
FAX 717-235-3231
-----Original
Message-----
From: John
DAmbrosia
[mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Monday,
August
14, 2006 5:20
PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject:
[HSSG]
MAC
Data Rate of
Operation Objective
All,
In regards to proposed
MAC data rates, I have seen two basic
proposals
Proposal A) 100 Gb/s
Proposal B) Scalable
Solution
Proposal A supports the
traditional 10x increase in
speed.
Proposal B, as presently
discussed, is unbounded. (The
following are only my observations of statements made on the reflector
by
others) The lowest limit proposed was a 4x10 approach for 40 Gb/s.
No upper limits have been proposed. It has been suggested that this
approach should use existing PMDs, but there have been also been
comments
regarding use of 10G, 25G, and 40G lambdas, but that carriers would
want to leverage
their existing DWDM layer, which mean baudrate in the 9.95-12.5 Gig. Consuming
wavelengths has been brought up as a possible concern. It was also
suggested that the greatest bandwidth demands are on VSR links < 50m
and
that the longer reach (>10km) may be able to live with 4x10G. (Data
in
support of these observations that could be used to guide the creation
of
objectives would be welcome.)
An objective for Proposal
A could be similar to what was
done for 10 GbE- Support a speed of 100.000 Gb/s at the MAC/PLS service
interface.
For Proposal B, given its
current unbounded nature and
multiple discussion points, I am not sure what would be proposed. I am
looking to the advocates of this proposal to provide some verbiage to
the
reflector for discussion. Using the objective above as a basis:
Support a
speed greater than 10.000 Gb/s at the MAC/PLS service interface, would
create
too broad an objective.
Also for both proposals
what are people's thoughts on an
objective that would specify an optional Media Independent Interface
(MII)?
John