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

RE: Why not have both?


Thanks for proposing a simple WAN/PHY specification.  We can move on from
here to generate a complete specification for HSSG.

I like the fact that your WAN/PHY is based on OC-192C signaling standard,
which is widely implemented in the marketplace - Light SONET.

Your proposal, surely, is a simple, bare-bone overhead, which I think will
do the job.

Nevertheless, if there is any other proposal, we should also discuss it.

Also, it is the time to start deal with those issues: 9.548...Gbps NRZ
scramble data, data rate conversion scheme (10.000/9.548.Gbps), framing,
recovered clock characteristics (should meet SONET jitter-transfer,
jitter-tolerance, and jitter-generation? Probably not), clock frequency
tolerance (100 ppm?), data jtter characteristics, BER, fault reporting,
SERDES, target distance (40 km max?), media......etc.


Ed Chang
NetWorth Technologies, Inc.

-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxx]
Sent: Sunday, September 12, 1999 6:09 PM
To: Edward Chang
Cc: stds-802-3-hssg@xxxxxxxx
Subject: Re: Why not have both?

Ed, Howard, all,

Now that a consensus has been achieved on developing separate PHYs for LAN
WAN, I can perhaps propose a specific implementation of the WAN compatible
I would recommend that the WAN compatible PHY be based on the OC192C
standard.  The majority of the sync frame will contain only static default
information, with the following exceptions:

H1, H2 - line overhead payload offset bytes - static data, numeric, "522"

J1 - path overhead trace byte - a static programmable 64 or 16 byte message
string to identify the 802.3 path ( I prefer 16 bytes because this would
make it
compatible with SDH also.)

B3 - path bit interleaved parity - dynamically calculated, binary

C2 - path signal label - static TBD

G1 - path status byte - dynamically determined from reverse link status

H4 in first STS overhead - path indicator byte - static "0"

H4 in remaining STS overheads - path indicator byte - static "concatenation

For those that may not be familiar with the above byte label definitions,
see pages 8 and 9 of the SONET tutorial at .  The majority of this
would not apply to 10GbE, but it will help some to understand the
practices of common services carriers.

As you can see.  I am recommending that only the path overhead have any
processing associated with it.  At that, only 2 bytes have fully dynamic
information; B3 and G1.  J1 will have data that will be repeating every 16
frames to be able to communicate the trace message.  Since service provider
transmission systems would insert their own  active information in the line
section overheads, it would not be necessary for 10GbE to supply active line
path information, only place holder bytes in the sync frame. I have gotten
than one vendor to unofficially agree that this would work as path trib to
either a "lite" LTE, or an active DWDM transponder.  I have also gotten
internal network management standards people to agree to this type of

I hope that this will help to speed the development of the WAN compatible
SNMP MIB entries will need to be defined for the path overhead information.
PHY to MAC management link will have to be defined to provide for the PHY
management and SNMP registration.

Thank you,
Roy Bynum
MCI WorldCom

Edward Chang wrote:

> Comments:
> I firmly believe the consensus to have both LAN/PHY and WAN/PHY is the
> direction for HSSG, which has been required by market for a while.  It
> enable us to share the Internet-wealth with WAN people who are looking for
> LAN people's help to further expand the market.
> We have to appreciate many people in the last two months devoted so much
> time on the reflector to explore all issues and gradually build up the
> consensus to move to enable both LAN/PHY and WAN/PHY proposals.  Not to
> mention Roy's persistent effort, there were many counter views to shape
> WAN/PHY model to a realistic, cost-effective concept.
> Both Howard and H.W Chin responded timely to propose
> LAN/PHY-bridging-WAN/PHY model, and a detailed OC-192c PHY were greatly
> appreciated by many of us, including myself.
> It is the time for us to move forward to develop MAC, LAN/PHY, and WAN/PHY
> specifications.  I believe we can develop a common MAC/PLUS to serve both
> LAN/PHY and WAN/PHY, as the example of other Ethernet MACs with a common
> interface, or 10GMII for 10xGbE. As they were discussed on the reflector,
> there are so many issues of LAN/PHY and WAN/PHY waiting for us to resolve
> them to convert into specifications.
> Howard's LAN MAC/PHY-BRIDGE-WAN MAC/PHY model is a great picture to ignite
> rally among us to support two PHYs.  It proved "a picture is worth 10 Giga
> words"
> Nevertheless, it seems that interconnecting LAN MAC/PHY and WAN MAC/PHY is
> the vendor implementation choices, rather than a standard issue.
> As long as we are using a common MAC for both PHYs, there are many ways of
> tying the I/O side of both MACs depending on the market needs.  With some
> kind of simple congestion control in a MAC chip, we can directly OR-TIE
> I/Os of LAN/MAC and WAN/MAC (common bus).  A simple buffered repeater as
> someone suggested, or one may add a peripheral controller for flow
> Implementing level-3 switch to have much more flexibility and complexity
> achieve various data rates, addresses, frame sizes...etc.  Of course, we
> go to the higher level, if we want.  Furthermore, the WAN MAC/PHY does not
> have to connect to a LAN MAC/PHY, instead, it can connect to other MACs;
> namely, 1xGbE, 100 Ethernet ..etc.  I believe, those innovative vendors
> come up with variety of conversion approaches to meet the market needs.
> Regards,
> Ed Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> I would like to request, in behalf of the HSSG, a presentation at the York
> meeting regarding the applicability of the "Gigabit Ethernet Model (i.e.,
> Hanson; Cunningham spreadsheet)" for use in our work on "ten Gig."
> This model was extremely helpful to us in 1000BASE-X in discussing
> Variations to the specifications and resolving issues. I expect, as with
> model, that there are certain underlying assumptions which might have to
> corrected (or at least tuned) for application in 10 Gig. At very least,
> there will be new techniques needed to use it for multilevel encoding, as
> example.
> Some things to consider:
> 1. Use of truly single mode LW lasers (Vs multiple longitudinal; single
> transverse mode)
> 1.1 Compensated by adjusting K only?
> 1.2 Chirp?
> 1.2 Measurement of spectral width (rate of drift of "single mode" Vs
> Characterization of spectra)
> 2. The inherent difference between rise and fall times
> 3. Assumptions about ISI penalty maximums for a link
> 4. Simultaneous support for:
> 4.1 Serial up to 12.5 Gig
> 4.2 Parallel / WDM down to ?
> 4.3 Support of various multi-level schemes
> 4.4 Channel to channel crosstalk issues
> 4.6 Assumptions for SMF and high performance BW MMF
> 5. Replacement of the E/R (per FC proposals)
> 6. The various recommendations made by Petar Pepeligoski (IBM)
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Howard
> Frazier
> Sent: Wednesday, September 08, 1999 8:52 PM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: Why not have both?
> >From the various statements posted to this reflector over the past
> few months, it has become obvious to me that the LAN and WAN
> markets have different needs when it comes to the physical layer
> of a network interface. I would also say that it is apparent that
> the HSSG is at an impasse.  I doubt very much that either the
> LAN devotees or the WAN devotees will be able to
> persuade their opposite numbers to abandon their well thought out
> and closely held beliefs and settle on a single Physical Layer
> definition that will serve both markets.
> Therefore, I encourage the HSSG to consider the development of
> two distinct PHYs for 10 Gigabit Ethernet.  Let's call one the
> LAN PHY, and the other, the WAN PHY.  Each of these specifications would
> optimized for the intended application.
> As others have already stated, it is possible to build a relatively
> simple, low cost, low complexity device that will bridge these
> interfaces together.  A layer diagram of such a device is shown in
> the attached PDF file.
> Referring to the diagram, on the left side, we have a cloud labled
> "LAN infrastructure".  This is made up of the switches, routers,
> hubs, NICs, firewalls, gateways, servers, desktops, etc, etc,
> that communicate via Ethernet.  On the right side, we have a
> cloud labled "WAN infrastructure".  This is made up of the
> transponders, multiplexors, regenerators, amplifiers, etc,etc,
> that conform to SONET specifications.
> In between these two clouds, we have a bridge.  In the context
> of 802.3 standards, this is an 802.1D bridge, but in practice,
> it could have more or less functionality than required by 802.1D.
> The primary purpose of this device is to hide all of the details
> of the underlying LAN and WAN PHYs from each other.  The
> PHYs can use completely different signaling methods, they can
> use different physical media, they can run at different rates.
> They can also have different management attributes.
> I assert that the cost of such a device is dominated by the cost
> of the PMD (the optical components) associated with the
> WAN interface.  I can't throw dollar figures around, but I can
> state with conviction that the sum of the costs for the LAN PMD,
> the LAN PHY, the LAN MAC, the Bridge, any associated memory,
> any associated microprocessor, the WAN MAC, and the WAN
> PHY, and associated management, is about 1/25th of the cost
> of the WAN PMD and its associated clock oscillator.  That's
> right. Relatively speaking, the WAN optics cost about 25 times
> as much as the rest of the components in the box combined.
> That tells me that such a device will definitely not be a barrier
> to the use of 10 Gigabit Ethernet in the WAN, and it might even
> be considered an "enabler", because it can connect to the LAN
> infrastructure just about anywhere you wish.  Of course, since
> I am suggesting that we specify a WAN PHY as well as a LAN
> PHY, it is possible to build an interface for an "Enterprise" LAN
> switch that provides a WAN PHY and PMD, and maybe this
> will happen.  The "Two PHY" approach allows inovation and
> optimization to keep pace with technology development, and
> the needs of the market.
> It will also let us get going in the HSSG, and put some of the
> arguments behind us.  To that end, I suggest that we:
> 1) Adopt an objective to specify a PHY optimized for LAN
> applications.
> 2) Adopt an objective to specify a PHY optimized for WAN applications.
> 3) Settle the "speed" objective by stating that the MAC/PLS
> interface always runs at 10.0000 Gb/s.
> This speed will work with either PHY.  For various reasons,
> the WAN PHY will require at least a packet's worth of buffering
> in each direction.  If you have to have the buffer, you might
> as well use it to match the 10.0000 Gb/s MAC/PLS rate to
> the 9.95328 baud rate on the WAN medium.
> 4) Agree that a pacing mechanism of some sort can be employed
> if necessary to throttle the MAC's transmit data rate down to a
> rate which is compatible with the payload rate of a WAN PHY.
> With a packet buffer in the PHY, this pacing mechanism can
> operate on a packet by packet basis.
> Note: If you were to design an integrated MAC and WAN PHY,
> you could get rid of the buffer and the pacing mechanism.
> 5) Agree that the two PHYs need to be individually justified in
> the "5 Criteria".  I am not suggesting that two PHYs means two
> standards projects (i.e. two PARs), but I do think that we need
> to answer the 5 Criteria for both PHYs, so that the rest of the
> world understands why we are doing this.  I think it will be
> easier to come up with words which justify the two PHYs
> individually than it would be to agree to one set of words that
> embraces both PHYs.
> Please give this suggestion some serious thought.
> Howard Frazier
> Cisco Systems, Inc.