Re: Why not have both?
Howard,
I agree with your proposal. I would prefer to refer the intersection between the LAN MAC/PHY and the WAN MAC/PHY as
"buffered repeater / data switch matrix". This would allow the WAN MAC/PHYs to possibly co-reside with LAN MAC/PHYs
on the same data switch, as well as on a stand alone buffered repeater. I also like that you have put to the side of
each PHY, a corresponding PHY MGT. This will allow each PHY to have the management functionality that is specific to
its implementation requirements.
Thank you,
Roy Bynum
MCI WorldCom
Howard Frazier wrote:
> >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.
>
> ------------------------------------------------------------------------
> Name: toophy.pdf
> toophy.pdf Type: Portable Document Format (application/pdf)
> Encoding: x-uuencode