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]