RE: 10xGbE on DWDM
- To: Paul Gunning <paulg@xxxxxxxxxxxx>, "'Bill St. Arnaud'" <bill.st.arnaud@xxxxxxxxxx>, "Jones, Nevin R (Nevin)" <nrjones@xxxxxxxxxx>, "Nuss, Martin C (Martin)" <nuss@xxxxxxxxxxxxxxxxxxx>
- Subject: RE: 10xGbE on DWDM
- From: "Langner, Paul (Paul)" <plangner@xxxxxxxxxx>
- Date: Mon, 7 Jun 1999 10:08:44 -0400
- Cc: bin.guo@xxxxxxx, rtaborek@xxxxxxxxxxxxxxxx, dwmartin@xxxxxxxxxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx, sachs@xxxxxxxxxxxxxx, widmer@xxxxxxxxxx, Iain_Verigin@xxxxxxxxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Martin Nuss asked me to forward you a link on some SDL specs, etc. They
can be found at:
Some additional comments:
1) SDL was designed to correct some flaws in POS, and can be used to map
data into any bit oriented link (i.e. into SONET or directly over fiber,
2) It uses x^48 set/reset scrambling as opposed to x^43 self-sync scrambling
as the x^43 is open to DC balance/transition density attacks on
clear-channel mappings. In non-clear channel mappings (such as STS-12 in an
OC-48) there are no issues and x^43 SSS works fine.
3) It suffers no byte expansion as seen by things such as 8B10B or byte
4) It has 2 messaging channels that allow 6 byte messages to be passed
between ends of the link (i.e. you can map GbE out of band signalling into
Any questions on this, let me know.
From: Bill St. Arnaud [SMTP:bill.st.arnaud@xxxxxxxxxx]
Sent: Sunday, June 06, 1999 3:44 PM
To: Paul Gunning
Cc: bin.guo@xxxxxxx; rtaborek@xxxxxxxxxxxxxxxx;
dwmartin@xxxxxxxxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx; sachs@xxxxxxxxxxxxxx;
Subject: RE: 10xGbE on DWDM
> I fully concur. I would welcome a pointer as to where I could
> find out some more information about the SDL protocol(s). It(they)
> sounds very, very interesting.
Lucent has been doing a lot of work in this area. I can't point you
specific paper, but I have seen numerous presentations from Lucent
Their web site might be a good place to start.
> I realise that. But is there a requirement for additional
> frame overhead in that you need a contiguous sequence
> of preamble "training" 'bits' at the front of the frame
> to phase sync. the Rx PLL?
If you have loss of sync that may be required, but in general I
believe there is a requirement for "training" bits
> Agreed. But there ARE clock management issues between
> adjacent nodes on a DPT ring in that you have to
> explicitly nominate a master and slave relationship.
Hmmm. I will have to check into this. DPT and Nortel's IPT which
similar allow for auto-discovery etc which implies that there is no
> Unfortunately I can't attend the meeting in Idaho
> but I would be very interested to learn of any proposals
> for 100xGBe.
I remain skeptical that we will see serial speeds beyong 10Gbps or
optical switches in the near future. The problem with serial speeds
excess of 10 Gbps is the processing required at switching or routing
Every router manufacturer I have talked to has found it exceedingly
difficult to build router interfaces that can work at 10 Gbps line
To do this a router must process an incoming packet, perform a
address table lookup and the forward the packet across a backplane
in a few
nanoseconds. At these speeds we are closely the physical limitation
light propagation across the phsical dimensions of the box.
Right now the I believe the propagtion time of an electrical signal
"copper on copper" semi-conductors is comparable to the speed of
through glass. But more importantly is the small component size of
semi-conductors versus existing opto-switching devices. At these
size of components and the length of their interconnection path
critical for high speed processing. As I understand it when you try
reduce optical components to the size and density as semi-conductors
approaching the wavelength distance of the actual light path which
whole set of new refractive and light bending problems. There was
excellent article in the last issue of Scientific American on this
Finally when you have serial speeds in excess of 10 Gbps you run
whole set of new non-linearities in the fiber itself. Polarization
dispersion, for example becomes very significant and now cannot be
Jitter and BER becomes increasingly tougher and tougher as well.
I think someday we will reach these speeds but maybe not serially,
through Silkroad's or Transact's technology solutions. But I don't
happening for several years.
> Yes. But deployment economics would tend to prefer DWDM
> so as to maximise bandwidth per physical fibre. DWDM allows
> you to have many additional "virtual" fibres per physical fibre.
The same economics apply to supercomputers. The cost per memory bit
supercomputer is significantly less than that of a a standard PC.
be more economical to move all our applications to supercomputers.
don't see many people doing that.
I think the same rationale will apply to DWDM. Yes, the cost per
signficantly less than CWDM and yes you can pack in many virtual
the upfront capital is very high. More importantly you are tied to
fortunes of your favourite carrier. Whereas if I can get access to
fiber I can install my own CWDM system at significantly less upfront
and I am in control of my own destiny.
We have actually been going through a detailed economic exercise on
very topic for a 1700 km regional network here in Canada. Even a
manufacturer of DWDM equipment had to admit that CWDM, particularly
10GbE is "significantly" cheaper than DWDM. Because the regional
in a small province the local carrier could not justify the upfront
cost of a DWDM system. But even if the carrier had the business
justify the upfront capital cost, the prorated DWDM cost was not
better than the total CWDM 10GbE cost!!