Re: Why not have both?
Henry,
I am repeating myself but I think that Howard's use of the term bridge
is correct because it relies on an existing concept with the broadest
possible abstraction. Adding a buffered repeater to the lexicon is
uncertain and unnecessarily reduces the abstraction level.
In general something that doesn't exist yet, also doesn't exist period.
Ariel
>
> Ariel,
>
> Yes, the buffer repeater does not exist yet in the reference model. But the
> concept is simple and repeater is a MAC device, and therefore can be
> addressed by 802.3 entirely. There is no need to go to any anywhere else to
> see if there is need for any additional definition. If we are going to
> define two PHYs of similar speed, then defining a buffered repeater should
> be quite straight forward using XOFF, which is also a MAC function.
>
> Henry Ngai
>
> ----- Original Message -----
> From: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>
> To: <stds-802-3-hssg@xxxxxxxx>; <pbottorf@xxxxxxxxxxxxxxxxxx>;
> <hngai@xxxxxxxxxxxx>
> Sent: Thursday, September 09, 1999 10:55 PM
> Subject: Re: Why not have both?
>
>
> > Henry,
> >
> > The essence of the concept is that there is a MAC on each side, and the
> > forwarding between LAN and WAN occurs at or above the MAC client
> > level.
> >
> > How the forwarding is accomplished is irrelevant. The "bridge"
> > nomenclature used by Howard is therefore appropriate. The "buffered
> > repeater" does not really exist elsewhere in the reference model.
> >
> > Ariel
> >
> >
> > > From: "Henry Ngai" <hngai@xxxxxxxxxxxx>
> > > To: "stds-802-3-hssg" <stds-802-3-hssg@xxxxxxxx>, "Paul Bottorff"
> <pbottorf@xxxxxxxxxxxxxxxxxx>
> > > Subject: Re: Why not have both?
> > > Date: Thu, 9 Sep 1999 14:27:25 -0700
> > > MIME-Version: 1.0
> > > Content-Transfer-Encoding: 7bit
> > > X-Priority: 3
> > > X-MSMail-Priority: Normal
> > > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > > X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > > X-Listname: stds-802-3-hssg
> > > X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> > > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> > >
> > >
> > > 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
> > > >
> > >
> >
> >
>