RE: Why not have both?
Bruce,
I believe Packet Engines (Alcatel?) still sells them. BDs do have a nitch
in providing access for intrusion detection purposes. Granted we are not
buying them in lots, but there is a use for them.
Mike Bennett
Lawrence Berkeley Laboratory
At 10:55 AM 9/10/99 -0700, Bruce_Tolley@3com.com wrote:
>
>
>Brad:
>
>My recollection is that 3 companies announced and shipped BDs: 3Com, Packet
>Engines, and XLNT. 3Com no longer makes or sells a BD.
>
> Customers voted NO with their dollars.
>
>I would be really surprised if the TOTAL market volume by all vendors
surpassed
>100 units. I am almost certain that no company currently sells any BDs.
>
>//Bruce
>
>
>
>
>"Booth, Brad" <bbooth@level1.com> on 09/10/99 10:41:01 AM
>
>Sent by: "Booth, Brad" <bbooth@level1.com>
>
>
>To: stds-802-3-hssg@ieee.org
>cc: (Bruce Tolley/HQ/3Com)
>Subject: RE: Why not have both?
>
>
>
>
>Henry,
>
>I have to agree with Ariel. The buffer repeater does not need to exist
>in the reference model because that is an implementation. There is
>nothing in the current 802.3z standard that describes a full duplex
>buffer repeater, yet there are a few companies that make these devices.
>Their implementations were not impeded by the standard, and their
>equipment was designed to conform with the 802.3z standard.
>
>Cheers,
>Brad
>
> -----Original Message-----
> From: Henry Ngai [SMTP:hngai@neec-usa.com]
> Sent: Friday, September 10, 1999 11:44 AM
> To: Ariel Hendel; stds-802-3-hssg@ieee.org
> Subject: Re: Why not have both?
>
>
> 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@Eng.Sun.COM>
> To: <stds-802-3-hssg@ieee.org>; <pbottorf@nortelnetworks.com>;
> <hngai@neec-usa.com>
> 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@neec-usa.com>
> > > To: "stds-802-3-hssg" <stds-802-3-hssg@ieee.org>, "Paul
>Bottorff"
> <pbottorf@nortelnetworks.com>
> > > 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@majordomo.ieee.org>
> > > X-Listname: stds-802-3-hssg
> > > X-Info: [Un]Subscribe requests to
>majordomo@majordomo.ieee.org
> > > X-Moderator-Address:
>stds-802-3-hssg-approval@majordomo.ieee.org
> > >
> > >
> > > 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@nortelnetworks.com>
> > > To: Henry Ngai <hngai@neec-usa.com>; stds-802-3-hssg
> > > <stds-802-3-hssg@ieee.org>
> > > 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@cisco.com>
> > > > >To: <stds-802-3-hssg@ieee.org>
> > > > >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@NortelNetworks.com
> > > >
> > >
> >
> >
>
>
>Attachment Converted: "c:\eudora\attach\att1.htm"
>