Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] HSSG MAC & PHY Options



Title:

Hi Joel,

4x25G was just an example, the XAUI-like 100G version ... maybe it's not
practical, could be ... for backplane interconnects, you may have to consider
eventually other modulation formats than just NRZ, e.g. Duobinary or PAM-4.
With the latter, your 25G signal would be just 12.5 Gbaud, so very close to
10G backplanes ... whether that is practical or not will depend on how many
channels and how much Xtalk you have since PAM-4 is more sensitive to Xtalk
(higher SNR requirement) than Duobinary or NRZ.

Anyway, main point was that you may wanna use something else than NRZ
for speeds >>10G over the backplane ...

And, of course, as you said, maybe five or six lanes could be technically
more beneficial than four ...

Marcus



Joel Goergen wrote:
Marcus,

I have to think about this more ... but haven't really changed my mind.

I do have a comment about 4x25Gbps ....  A while back, I would have supported this.  But have done considerable research into the electrical dimension, I would rather see 5x22Gbps (something 20 to 22.2).  The issue is that the serdes itself would have to be 25 to 27gbps.  The electrical channel is tough at 27 for way too many people ... includes tx all the way through to rx.  But 22.2Gbps max speed works well in most connectors and many materials.  Also works well for back plane design since 10x10  on a back plane with high density port concentrations is just not feasible.

-joel

Marcus Duelk wrote:

Hi Joel,

I don't think that the channelized scalable PMD interface is so scary,
I mean most packet interfaces on your line card will be channelized
anyway (e.g. SPI-6), so that scalable "B-MAC" could also employ
some sort of channelized electrical interface, that way the channelized
scalable B-MAC really becomes like a WAN mapper.

If the MAC does not have a channelized electrical interface then
you won't be able to support 'VCGs' on the physical layer. That
would mean you may end up in that situation that Roger mentioned
where you have one B-MAC that scales up to 40G and another
B-MAC that scales up to 100G, but the latter one would not be
able to make use of the remaining 60G capacity.

As for interoperability, I think that probably an A-MAC and a B-MAC
will not be compatible, most likely their PMDs will even not match. I mean,
the corresponding PMDs for an A-MAC could be

a) 10x10G
b) 4x25G
c) 100G serial

while the corresponding PMDs for a B-MAC would be

d) Nx10G

if we stick to only 10G rate per lane/wavelength.

As for buffer sizes, if you have only point-to-point links and the only
differential delay is due to chromatic dispersion and other skew inside
the transceivers or on the boards, then you probably can do the delay
compensation with on-chip memory, which is better. If you want to
consider path diversity on the optical layer or delay compensation only
at the end nodes you will need external memory which will ultimately
increase costs and design complexity. Especially if we think of a 100G
memory interface ...

Marcus



Joel Goergen wrote:
All,
I agree with point (1) below from Marcus.  To do anything else really complicates the system design.

I would not want to think about (3) ... Ethernet is cost effective and easy to deploy.  Adding that kind of complexity to the architecture, as well as the additional network engineering cost ... would not be Ehternet ... okay ... actually, it scares me :).

I'd like to see option A and B combined ... a single 100Gbps device supporting lanes or lane, with an ability to negotiate the number of lanes and perhaps lane rate (10, 20, 100).  This puts us in a position to have multiple lane devices now, but lower cost serial devices in the future (similar to the xaui - xfi relationship).  This device could run in diminished capacity with perhaps a lane missing.

However, all lanes need to function similar to xaui type concepts in that the fifo or buffer size needs to be reasonable.  We (the network industry) don't have the types of memories available to have 10 lanes with ten sets of huge buffers.  I couldn't possibly fit all that on a board for a single interface, let alone consider how to scale the number of interfaces for cost.

-joel

Marcus Duelk 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

-- 
___________________________
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

-- 
___________________________
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