| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Bruce,
That was exactly my point, the 802.3z standard did not prevent the design and manufacture of BDs, even though there is nothing in the standard that describes a BD implementation. As for the BD's life cycle, that's another story. J
Thanks,
Brad
-----Original Message-----
From: Bruce_Tolley@xxxxxxxx [SMTP:Bruce_Tolley@xxxxxxxx]
Sent: Friday, September 10, 1999 12:56 PM
To: Booth, Brad
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: Why not have both?
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
> > >
> >
>
>
<< File: Internet HTML >>