Re: Why not have both?
Paul,
I believe you are correct. I suggest a buffering repeater so we don't have
to describe and refer to bridges and routers. A buffering repeater also
addresses Roy's concern on security. By default, a buffering repeater does
not understand any information contained in the packet. It can also be a
great signal repeater.
Henry
----- Original Message -----
From: Paul Bottorff <pbottorf@xxxxxxxxxxxxxxxxxx>
To: Henry Ngai <hngai@xxxxxxxxxxxx>; stds-802-3-hssg
<stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, September 09, 1999 12:26 PM
Subject: 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
>