David,
One of the "mistakes of 10G"
was having effectively defined MACs of two
slightly
different rates - one for LAN PHY and the other for WAN PHY.
While one might assume that one would select the correct
interface for
the correct purpose, experience has
shown that this is not the case. We
have way too
many examples of cases where someone builds something
around a 10G LAN PHY and then expects it to be transported with
absolute
bit transparency across a wide-area network
(e.g., a secure government
application where they
insist that the service provider not touch the
payload).
While some vendors have provided proprietary solutions
(e.g., an OTU2
like frame structure at a higher
clock rate), there is no standard way
to do this.
There are a comple of different proprietary mappings that do
not interwork with each other. None of them work in other
than a
point-to-point configuration. Since the
operate at a higher bitrate,
they don't have the
spectral characteristics of G.959.1 interfaces. They
don't have the clock accuracy required in G.709 or follow the
jitter/wander characteristics of G.8251. And they can't be
multiplexed
up to standard OTU3 40 Gbit/s
interfaces.
I think that it is extremely important to avoid this debacle
at the next
rate. We can certainly use a variety of
different physical interfaces,
but to have a variety
of slightly different payload bitrates is a
disaster.
Regards,
Steve
-----Original Message-----
From:
David Law [mailto:David_Law@xxxxxxxx]
Sent: Thursday, August 24, 2006 3:10 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach Objectives
Hi Steve,
I just wanted to make sure I understand what you are
advocating here.
You suggest that if we are
considering using lanes 'on the order of 10Gb
in
size' in size we should select a rate that exactly fits into an
STM-64/OC-192 or G.709 OPU2 payload. Further you state that
there should
only be one PHY type. Now taking the
case of STM-64/OC-192, the
conclusion I draw is that
you are advocating for any Aggregation at the
Physical Layer (APL) objective is a MAC data rate of n x 9.58464
Gb/s,
and mandatory use of the Clause 50 WIS with a
resultant baud rate of
9.95328 Gb/s per lane.
If there is an APL related objective why would it not
support
aggregation of both of the existing 10Gb/s
LAN and WAN PHY types (see
slide 25 of CFI
presentation), including all related PMDs, just as
Clause 43 Link Aggregation does at the moment, it seems rather
arbitrary
to not allow APL to use the LAN PHY when
it already exists.
Regards,
David
"Trowbridge, Stephen J (Steve)" <sjtrowbridge@xxxxxxxxxx>
wrote on
23/08/2006 15:48:09:
> Drew,
> I think you are
touching on some important points here where we need
> to be VERY careful.
> I think that many will agree that a key mistake of 10G
was to develop
> a LAN PHY and a WAN PHY that
operated at a different payload bitrate.
> The
WAN PHY was important because, as has been discussed, 10G was
> where we really got into having Ethernet as an
Infrastructure
> interface, so it needed to work
seamlessly into transport networks.
> But we
should have selected a bitrate that works into all transport
hierarchies.
> As far as compatibility with transport technologies, a
few thoughts:
> - If we are considering multiple
lane approaches and have the idea to
> carry the
lanes individually across a transport network, it is
> essential to consider the technologies used in those transport
> networks. For example, if we are considering
lanes on the order of 10G
> in size, we should surely select an exact rate that
fits into an
> STM-64/OC-192 or
> G.709 OPU2 payload. If we also want to carry such a lane over a
10G
> LAN PHY, we should limit the data rate used
over that iterface so that
> it still fits into the transport network.
> - Regarding differential delay or skew, it depends on
the underlying
> transport technology and the
network span before reaggregating. With
>
SONET/SDH, you are dealing with a basic frame rate of 125
> microseconds, so virtual concatenation in this environment needs
to
> consider several frames worth of
differential delay. With G.709,
> however, the
framing is essentially to give you OAM, a multiplex
> structure, and FEC rather than being tied to the payload rate.
At 10G,
> the G.709 frame is just over 12 microseconds, and at
40G it is just
> over 3 microseconds. So the
differential delay required to be
> compensated
for virtual concatenation in G.709 is only 125
microseconds.
> You mention the over-clocking of G.709 to carry LAN
PHY. While this
> appears in some networks for
point to point, it is not according to
> the
standard, does not work with all equipment or components, and is
> not networkable (for example, you can't
multiplex these over-clocked
> signals into a
standard G.709 OTU3 (40G) signal). There has been a lot
> of angst in standards discussions about how to limit
the proliferation
> of these kinds of solutions and get back to a coherent
network
> architecture Since we are starting out
in HSSG with a "clean slate" to
> define a new interface and have the freedom to
select:
> - Rates that match for the networks we
want to interwork with
> - Payloads that fit into
the containers we want to carry them I think
> we
should NOT look to some of these special case implementations for
> how to build a new interface, but to the
standards for the
> technologies where
interworking or transport is important.
> Finally, when (not if) we get to looking at 100G
serial, I think we
> should remember the pain of
10G LAN PHY/WAN PHY and avoid repeating
> that
experience. The ideal situation is if we could agree on a data
> rate, frame format, etc. that meets everybody's
needs (not to mention
> generating extra volume
with common technology to bring costs down). I
> think that it would be a good idea to work with the
ITU-T to see if we
> could define a common, sensible evolution that works
for data and
> transport environments (of course
the lines between these are becoming
> increasingly blurred). It certainly wouldn't hurt to be
working with
> the
>
G.709 guys in ITU-T Q.11/15, and the optical physical interface guys
> in ITU-T Q.6/15.
> You may recall that Glenn Parsons had described the
fact that IEEE is
> now a sector member of ITU-T,
and that plans were underway to hold a
> joint
workshop in Late May in Geneva, probably between an ITU-T hosted
> IEEE 802.1 and or 802.3 interim meeting and the ITU-T
Study Group 15
> meeting. This could be a good
opportunity for some face-to-face work
> on these
topics. We can certainly correspond via liaison statements
> earlier.
> Regards,
> Steve
>
>
________________________________
> From: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx]
> Sent: Wednesday, August 23, 2006 1:02 AM
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reach Objectives
>
> Menachem,
>
> I think we need to
differentiate between what PMDs we specify and what
> other PMDs we enable. For instance, I don't think it is
the IEEE's
> place to specify an ULH PMD in terms
of the optical specifications.
> However, this
could be one of the more important applications of a HS
> Ethernet. So I think it would be worthwhile for us to enable
vendors
> to develop it in a straightforward
fashion. Thus I think we should get
> into some of the details that you mention
including:
> 1. PHY layer - what degree of
compatibility with LAN-PHY,
> WAN-PHY
(SONET/SDH), and/or G.709 is desired?
> 2. What amount of differential delay
(skew) will be allowed?
> What will be mandated
for all conformant implementation?
>
> It is clearly desirable to
maintain compatibility with today's DWDM
>
transponders. This is a specific goal of some carriers that are
> participating in this process. Carriers would
love to have a PMD
> option that leverages the
10G LAN-PHY or WAN-PHY. Of course this will
>
depend on the answers to these questions and other decisions we make.
>
> Many (I believe most) DWDM
systems on the market now support the
> LAN-PHY
natively by simply speeding up the G.709 OUT to run at ~11Gb/s
> instead of 10.7Gb/s rather than by doing some sort of
overhead
> compression into SONET/SDH or the
G.709 digital wrapper.
>
> Drew
> _____________________________
>
> Drew Perkins
> Chief Technology Officer
> Infinera Corporation
> 1322 Bordeaux Drive
> Sunnyvale, CA 94089
>
> Phone:
408-572-5308
> Cell:
408-666-1686
> Fax:
408-904-4644
> Email: dperkins@xxxxxxxxxxxx
> WWW : http://www.infinera.com
>
>
_____________________________
>
> -----Original
Message-----
> From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, August 22, 2006 5:00 PM
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reach Objectives
>
> Geoff,
>
> Thanks for your
comments.
>
> I also believe that our
efforts should focus on distances no higher
>
than 10's of Km (up to and including metro).
>
> If we decide as a group
that it is an objective to make it easy to
> hook
into LH and ULH transport systems in the installed base, we will
> have to study a number of issues such
as:
>
> (A) should we pick a data
rate that is matching SONET rates?
> (B) should we design our 802.3 std so that it tolerates
a much larger
> inter-lane differential delay
than what would be expected in a metro
>
application of the standard?
> (C) should we assume we never go through existing LH
transponders and
> just have to COEXIST on the
same fiber, optical amplifiers, dispersion
> compensators located in the huts, optical mux demux at
both ends etc.
> Etc. In this case we would assume a new type of LH
tranponder purpose
> built for HSSG
applications.
> If this is the case, SONET rate compatibility would not
be important.
>
> Today's 10G LH and ULH
system run mostly at OC-192 rates plus FEC
>
overhead. Chip vendors were creative and managed to find ways to
build
> devices that pack into these solutions the full 10G LAN
data rate even
> though OC-192 is less than 10G.
> I think (but I may be wrong) that they use available
bandwidth in the
> management bits available in
Digital Wrapper or something like that.
> Not clean but seems to work...
>
> Cheers,
> Menachem
> Menachem Abraham
> Columbus Advisors
>
> -----Original
Message-----
> From: "Geoff Thompson" <gthompso@xxxxxxxxxx>
> Date: Tue, 22 Aug 2006 16:09:11
> To:mabraham@xxxxxxxxxxxxxxxxxxxx
> Cc:STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reach Objectives
>
> Menachem-
>
> Thanks for your much more
specific answer to the question. I'm afraid
>
that my earlier answer was handicapped by my ignorance of the
> specifics of that market.
>
> Based on what you said, I
believe the questions for us to consider or
> not
are:
>
> a) Will we consider long
haul solutions.
> OR
> b) Will we limit ourselves to metro solutions and
"transport end"
> (i.e. stuff that hooks into the
transport infrastructure) solutions.
> Back in the old days of 10Gig we spent an awful lot of
time discussing
> the need for the WAN PHY to address case "b)". I think
most of us
> didn't get it then. I would hope
that with a different cast of
> characters
involved in the discussions that we (or at least I, for
> one) could come out with a clear rationale for what we
choose.
>
> (Just FYI, I believe the
crux of the issue came down to whether or not
> one could have a 2 port bridge, as opposed to an
> Optical-Electrical-Optical repeater in a
Transport Chassis.)
>
> None the less, I believe
that my proposed answer stands. We don't need
> to tackle this issue in the first set of objectives and
projects.
>
> I do remain interested
(old repeater hack that I am) in looking into
>
an O-E-O repeater that does not necessarily come all the way back up
> to the level of reassembling the full
packet.
>
> Geoff
>
> At 01:30 PM 8/22/2006 ,
Menachem Abraham wrote:
> All,
>
> If we decide to include in
our reach objectives Long Haul (e.g.
> 1000 km
with
> optical amps placed at 80 Km spacing) and Ultra Long
Haul (e.g.
> 3000 Km with
> optical amps at 80 Km spacing, without
Optical-Electrical-Optical
> regeneration), we need to keep in mind that
modulation/encoding/FEC
> choices
> play an important role in how far we can go on an
optical amplifier
> based
> line system. Such PMD designs may be too costly for our
< 80Km
> applications/objectives so we may end up with more
PMDs.
>
> While there are some
examples of Routers / Switches which have LH or
>
ULH
> optical interfaces built in, most systems use Routers /
Switches with
> shorter reach interfaces connected to separate
Transport Chassis that
> house
> proprietary LH or ULH solutions. As far as I know the
LH and ULH world
> does
> not have interoperable standard solutions today in
terms of the
> signaling on
> the fiber.
>
> My input for our
activities in HSSG is to optimize for cost and not
> require
> that one of our PMDs be directly useable as part of a
LH or ULH line
> system
> (unless that is doable without incremental
cost).
>
> Having said that, I
believe we should debate the need to address "ease
> of
> HSSG data transport" on top of existing and emerging LH
and ULH
> transport
> systems. If this debate already happened as part of the
10G
> 802.3 standard
> development and the conclusions apply here, perhaps
somebody can
> educate
> those of us who were not involved at that time.
>
> Thanks,
> Menachem
>
> -----Original
Message-----
> From: Aaron Dudek [mailto:adudek@xxxxxxxxxx:
> <mailto:adudek@xxxxxxxxxx> ]
> Sent: Tuesday, August 22, 2006 12:50 PM
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reach Objectives
>
> Geoff,
> Shouldn't the migration to ULH systems have any impact
on the spacing
> and hence be taken into consideration? Or is that
beyond the scope for
> now?
>
> Aaron Dudek
> (703) 689-6879
> Sprintlink Engineering
> adudek@xxxxxxxxxx
>
> On Tue, 22 Aug 2006, Geoff
Thompson wrote:
>
> > Roger-
> >
> > At 03:47 AM 8/22/2006 , Roger Merel wrote:
> >
> > Agree with
Drew. Have a few additional comments on
>
other reachs:
> >
> > For reach
objectives, we should start with customer
> based
needs (for
> broad market potential) and only amend if an
> > obvious
technical limitation with compelling economics
>
can t readily
> meet the broad customer need.
> >
> >
Specifically:
> >
> > - Long Reach
probably should be set at 80km rather than
>
100km (as
> this is the common hut-to-hut amplifier spacing
> > in
telecom)
> >
> > - While 50m
does serve a useful portion of the market
>
(smaller
> datacenters and/or the size of a large computer
> > cluster), it
is somewhat constraining as I ve been lead
>
to
> understand that the reach needed in larger
datacenters
> > is continuing
to out-grow the 100m meter definition but
> the
100m
> definition at least serves the customer well.
> > Certainly
10G-BaseT worked awfully hard to get to 100m
>
(for
> Datacenter interconnect).
> >
> >
> > I wouldn't attach a lot of creedence to the
10GBASE-T goal
> for 100 meters.
> It was, I believe, mainly driven by the
> > traditional distance in horizontal (i.e. wiring
closet to
> desktop)
> distances rather than any thorough examination of
data
> > center requirements.
> >
> > Geoff
> >
> >
> > - For both
in-building reaches (50m & 300m; or 100m &
> 300m), the
> bigger issue which affects the PMD is the loss
> > budget arising
from the number of patch panels. The
>
shorter /
> datacenter reach should include a budget for 1
> > patch
panel. The longer / enterprise reach should
> include a budget
> for 2 patch panels (one in the datacenter and
> > 1 in the
remote switch closet).
> >
> >
> >
> >
> > From: Drew
Perkins [mailto:dperkins@xxxxxxxxxxxx:
> <mailto:dperkins@xxxxxxxxxxxx>
]
> > Sent: Tuesday,
August 22, 2006 1:24 AM
> > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > Subject: Re:
[HSSG] Reach Objectives
> >
> >
> >
> > John,
> >
> >
> >
> > I suggest
dividing Metro into Metro Short Reach at 10
> km
(equivalent
> application to 10GBASE-LR) and Metro
> > Intermediate
Reach at 40 km (equivalent application to
>
10GBASE-ER).
> >
> >
> >
> > Drew
> >
> >
_____________________________
> >
> >
> >
> > Drew
Perkins
> >
> > Chief
Technology Officer
> >
> > Infinera
Corporation
> >
> > 1322 Bordeaux
Drive
> >
> > Sunnyvale,
CA 94089
> >
> >
> >
> > Phone:
408-572-5308
> >
> >
Cell: 408-666-1686
> >
> >
Fax: 408-904-4644
> >
> >
Email: dperkins@xxxxxxxxxxxx
> >
> > WWW : http://www.infinera.com:
> <http://www.infinera.com/>
> >
> >
> >
> >
> >
> >
_____________________________
> >
> >
> >
> >
>
>
______________________________________________________________________
> __
> ____
>
________________________________________________________
> > From: John
DAmbrosia
> [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx:
> <mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx>
]
> > Sent: Monday,
August 21, 2006 9:38 PM
> > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > Subject:
[HSSG] Reach Objectives
> >
> >
> >
> > All,
> >
> > We have had
some conversation on the reflector
> regarding
reach
> objectives. Summarizing what has been
discussed
> > on the
reflector I see the following
> >
> >
> >
> > Reach
Objectives
> >
> >
Long-Haul --> 100+ km
> >
> >
Metro --> 10+ km
> >
> > Data Center
--> 50m & 300m
> >
> >
> >
> > Data Center
Reach Segregation
> >
> >
Intra-rack
> >
> >
Inter-rack
> >
> > Horizontal
runs
> >
> > Vertical
risers
> >
> >
> >
> > Use this data
to identify a single low-cost solution
> that
would
> address a couple of the reach objectives
> >
> >
> >
> > Other
Areas
> >
> > During the
course of the CFI there were individuals who
>
wanted
> Backplane Applications kept in for
consideration,
> > but I have not
heard any further input in this area.
> Are
there
> still individuals who wish to propose Backplane
> > as an
objective?
> >
> >
> >
> > John
> >
> >
> >
> >
> >
> [attachment "C.htm" deleted by David
Law/GB/3Com]