RE: Why not have both?

["Booth, Brad" <bbooth@xxxxxxxxxx>]

Title: RE: Why not have both?

Great picture... definitely speaks a thousand words.

I agree that there is a need for two distinct PHYs (PCS and PMA) to service the WAN PMD(s) and the LAN PMD(s).  From the discussions on the reflector, I believe that the HSSG has come to a similar consensus.

I agree that a 10.0 Gb/s MAC/PLS data rate with a pacing mechanism will satisfy the requirements of the WAN.  I believe that by setting a goal of 10.0 Gb/s for the MAC/PLS data rate, we will make the standards work an easier task.  I think that we could also add a note in the "standard" to indicate that the 10GMII or XGMII can be designed to operate at a lower data rate for WAN-specific implementations.  I don't think we need an objective for that (because it is too specific), and I'm sure the WAN people will keep us honest about it.  I feel that the pacing mechanism is going to be a tough issue, but at least if we set the objective then we can worry about how to do it once we get the PAR and critters (5 criteria) done.

Thanks for putting that together.  I hope others realize that the objectives you listed don't impede various implementations but enable us to proceed with a well-defined standards focus.

Thanks,
Brad

-----Original Message-----
From:   Howard Frazier [SMTP:hfrazier@xxxxxxxxx]
Sent:   Wednesday, September 08, 1999 7: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 be 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. << File: toophy.pdf >>