Re: Why not have both?
Henry:
Probably the juncture between a LAN PHY and a WAN PHY is going to be a
router/L3-switch rather than a bridge. Howard's model gives us a good
architectural reference which could be simplified latter to a buffering
repeater like or included in a router.
Paul
At 10:59 AM 9/9/99 -0700, Henry Ngai wrote:
>
>Howard,
>
>I believe you are right in shooting for two different PHYs. However, I do
>not think bridge is a good way to join the two MACs and PHY together. Unless
>we impose the implementation of a bridge with all its overhead on the WAN
>link. A better approach to explain the simplicity of such a device may be a
>buffering repeater.
>
>As a buffering repeater, there is no need to worry about how STA works in
>this environment, nor is there need for bridge MIBs.
>
>Rate differences, in case of over 95% utilization at the 10G side of the
>network, can be handled by XOFF protocols.
>
>Henry Ngai
>
>
>----- Original Message -----
>From: Howard Frazier <hfrazier@xxxxxxxxx>
>To: <stds-802-3-hssg@xxxxxxxx>
>Sent: Wednesday, September 08, 1999 5:51 PM
>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.
>
>
>----------------------------------------------------------------------------
>----
>
>
>>
>
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx