Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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@xxxxxxxx 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@xxxxxxxxxx> on 09/10/99 10:41:01 AM
>
>Sent by:  "Booth, Brad" <bbooth@xxxxxxxxxx>
>
>
>To:   stds-802-3-hssg@xxxxxxxx
>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@xxxxxxxxxxxx]
>     Sent:     Friday, September 10, 1999 11:44 AM
>     To:  Ariel Hendel; stds-802-3-hssg@xxxxxxxx
>     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@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
>     > > >
>     > >
>     >
>     >
>
>
>Attachment Converted: "c:\eudora\attach\att1.htm"
>