Re: [HSSG] Reach Objectives
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]