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

RE: Why not have both?

Sounds like you've hit on a very popular solution.  I certainly support it.


> ----------
> From: 	Howard Frazier[SMTP:hfrazier@xxxxxxxxx]
> Sent: 	Wednesday, September 08, 1999 5:51 PM
> To: 	stds-802-3-hssg@xxxxxxxx
> Subject: 	Why not have both?
> <<File: toophy.pdf>><<File: ATT132542.txt>>
> 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.