Re: [HSSG] HSSG MAC & PHY Options
All,
Coming from a lasers (PMD) background, I have a few concerns with scenario B:
1) Vendor Arms Race diluting economies of scale:
Specifically, there is some likelihood that vendor A will annouce an
HSSG compliant interface that operates at nxM Gbit/s (M=10?). Then
vendor B will announce an HSSG compliant interface that operates at
(n+a)xM Gbit/s (a=1 or 4 or ?). As each vendor promulgates their
solution it reduces the commonality of that solution -- eg. a single
module supporting a 60G interface would likely use a different
technical approach than a 40G or 100G module. This divides up the
industry into working on different problems -- this has the potential
of scaling with (HD-DVD vs. Blu-Ray)^n -- where 'n' is the number of
commercially offered flavors of HSSG.
2) MAC bandwidth management:
In Marcus Duelk's example, 100G HSSG MAC linking up to two other MACs
operating at 40G & 60G respectively faced a simple task. How do we
divide up the bandwidth if there are two 60G MACs vying for the 100G
port?
3) End user perception that "higher speed ethernet" should be
transmitted from a single port:
My rudimentary understanding of end-user operation of these future
HSSG systems inclines me to believe that users will want a single HSSG
port. For example, I find it hard to believe that a multitude of
end-users will want to purchase a 40G HSSG that is implemented with 4
XFP modules instead of purchasing a 4 by 10GbE using 4 XFP modules.
To look back, we never saw much traction in the notion of delivering
LX4 using 4 SFP modules even though this would be much akin to the
physical implementation that we are discussing for option B.
4) Extra optical budget for WDM use of PHY:
Please be aware that not all of the optical 802.3ae/aq PMDs are
created equally in terms of excess optical budget. If we pursue a WDM
(wavelength division multiplexing) solution, we will need to allocate
additional optical budget to the the losses associated with both
multiplexing and demultiplexing the lanes. The manner in which the
losses scale (wavelength spacing, number of lanes, center wavelegth)
depends upon the technical method used for the multiplexing and
demultiplexing.
5) Scaling across wavelengths:
Optical fiber has a finite range of acceptable wavelengths suitable
for transmission. If we pursue WDM then each lane of 'M' in the nxM
Gbit/s should possess a unique wavelength in a non-ribbon fiber PMD.
We should create some optical spacing/offset between the adjacent
lanes of 'M' data -- eg. M1 operates at 1310nm & M2 operates at
1310+delta nm. The size of delta will impose a limit to the scaling
of 'n'. How does vendor A's system running at nxM Gbit/s map to
(n+a)xM Gbit/s in terms of wavelengths?
Thanks,
--Matt Traverso
Opnext, Inc.
mtraverso@xxxxxxxxxx
Note - I sent this from a personal account to avoid an automated
statement from my IT dept which contains phrases that would likely be
considered "unfriendly" to the reflector.
On 8/15/06, Marcus Duelk <duelk@xxxxxxxxxx> wrote:
>
>
> Hi Roger,
>
> just a few comments from my side:
>
> 1) I think that in any case the MAC has to be a single-chip
> with an internal bus of XY Gb/s throughput, no matter whether
> this is about option A or option B. I think you have to have one
> device that is monitoring the PMDs and that is sending data byte-
> or bit-sliced over multiple PMDs, fibers, wavelengths or whatever.
>
> 2) Interoperability between Option A) [single 100G MAC] and
> Option B) [scalable MAC] is an interesting point, I would expect
> that this would be required. If you have one "A-MAC" talking to
> one "B-MAC", the latter not being able to offer an aggregate bandwidth
> of 100 Gb/s, then the question is what these two MACs will actually
> agree on ... maybe you can not always have interoperability !? Sounds
> like a potential problem.
>
> 3) If you have one "B-MAC" with 100G total throughput and one
> "B-MAC" with 40G total throughput, both being scalable with a 10G
> granularity, then these two "B-MACs" would negotiate 40G as their
> service rate. The first 100G "B-MAC" would still have 60G remaining
> capacity, so could for example talk on a second channel to another
> 40G B-MAC and on a third channel at 20G to another MAC ... it
> basically becomes a channelized interface with 10G (for example)
> granularity.
> Similar to a WAN mapper you would define a VCG with N members of 10G,
> so each scalable B-MAC would/could support multiple VCGs at the same time.
>
> Marcus
>
>
>
>
> Roger Merel wrote:
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
> ________________________________
>
>
> From: Belopolsky, Yakov [mailto:ybelopolsky@xxxxxxxxxxx]
> Sent: Tuesday, August 15, 2006 7:16 AM
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] MAC Data Rate of Operation Objective
>
>
>
>
> Hello John,
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
> --
> ___________________________
> Marcus Duelk
> Bell Labs / Lucent Technologies
> Data Optical Networks Research
>
> Crawford Hill HOH R-237
> 791 Holmdel-Keyport Road
> Holmdel, NJ 07733, USA
> fon +1 (732) 888-7086
> fax +1 (732) 888-7074
>