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

RE: PHYs with 10.000 and 9.584640



Title: RE: PHYs with 10.000 and 9.584640

I strongly disagree with the comments in your last paragraph. I think part of the reason we are having these discussions is because Ethernet's popularity has continued to grow and its influence expanding beyond the traditional LAN into other areas. I've heard the argument for years that ATM would replace ethernet in the LAN environment because it had management, QOS, etc. However, it is clear that not only has ethernet not been replaced, but it has migrated out beyond the LAN.

A lot of these arguments were made in the old token ring vs ethernet wars and ethernet won because of its simplicity and, therefore, lower cost of implementation. Most of the management can be added in the upper protocol layers without unduly adding complexity and cost to those implementations that don't need it.

If the data rate is really an issue, let's work on a simple pacing mechanism to allow easy integration into legacy WAN environments.

Walter Thirion
Level One Communications
512-407-2110


> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Roy Bynum
> Sent: Saturday, July 24, 1999 8:22 PM
> To: Booth, Brad
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: PHYs with 10.000 and 9.584640
>
>
>
> Brad,
>
> From an architectural view I am confused about the insistence
> on a 10.0
> Gigabit data rate at the MAC.  I have implemented more than a few LANs
> and extended LANs over the years.  I have yet to see one sustain a
> modulo 10 transfer rate regardless of the signal rate.   There are
> vendors that are implementing a 10GbE that is really an interleaved
> 8xGbE.  That is not a 10.0 MAC, and it is receiving market exposure.
> There is even a very inexpensive LAN version of POS that is being
> discussed.
>
> Will not adding PHY speed control at the MAC,  just increase
> the cost of
> the MAC as well as the PHY?  It also adds to the complexity
> of the chips
> that it is implemented through, adding to the delay of deploying a
> viable 10GbE.
>
> Optical networking using SMF was not part of a 802.3 LAN environment
> when it was introduced.  If I had been part of the GbE task force, I
> would have greatly opposed SMF as a WAN implementation without WAN
> operational support.  From a future markets, architectures, and
> implementations view, that is the real crux of this discussion.
>
> What I have seen is that with an extended optical PHY, 802.3 has
> encroached into architectural implementations that can not be
> supported
> long term.  With a 10km SMF PHY, GbE is being implemented
> across leased
> dark fiber without any operational support for these fiber facilities.
> This will create a major cost of support that is not traditional with
> 802.3.
>
> There is a massive market for a non 10.0 MAC rate.  Do you want to
> concede this market to existing WAN protocols?  Do you want to see the
> WAN protocols invade and take over the intra-facilities LANs?
>  Without a
> ~9.5 MAC it will be easier to implement a WAN protocol as a common
> enterprise facility than it will be to implement 802.3.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>
>
>
> "Booth, Brad" wrote:
>
> >
> >
> > Jaime,
> >
> > In essence, this is placing the burden on the subset of PHY
> > implementers.  I'm not advocating a PHY that works at two rates, I'm
> > advocating a MAC/PLS that works at one rate - 10Gb/s.  The
> PHY's would
> > map the MAC/PLS data rate to their corresponding data rate, and in
> > this architecture, only the WAN PHY would have to do
> something special
> > to decrease the data rate to 9.58464 Gb/s.  Maybe a new PHY sublayer
> > is necessary to perform the data rate mapping.
> >
> > I don't think we require two separate PARs because of the
> differences
> > in a LAN PHY compared to a WAN PHY.  What I believe is
> required is to
> > isolate where the differences between these two types of
> networks are,
> > and I believe that can be done by having a LAN PHY and a
> WAN PHY.  To
> > the system designer, the implementation becomes easier if they can
> > pick a 10GbE MAC and plug it to a PHY of their choosing.  The PLS
> > service interfaces are the same and the operations inside
> the MACs are
> > the same, only the PHYs are different: one is LAN capable, and the
> > other is WAN capable.  Keeping this all in one PAR can help to
> > guarantee this interoperability of MAC, PLS and PHY.
> >
> > Thanks,
> > Brad
> >
> > Brad Booth
> > bbooth@xxxxxxxxxx
> > Level One Communications, Austin Design Center
> > (512) 407-2135 office
> > (512) 589-4438 cellular
> >
> >      -----Original Message-----
> >      From:   Jaime Kardontchik [SMTP:kardontchik.jaime@xxxxxxxxxxx]
> >      Sent:   Thursday, July 22, 1999 1:03 PM
> >      To:     stds-802-3-hssg@xxxxxxxx
> >      Subject:        PHYs with 10.000 and 9.584640
> >
> >      Hello Brad and other 10G'ers:
> >
> >      This looks to me like throwing the problem to the subset of PHY
> >      implementers,
> >      since the HSSG (read subset of marketing, system and MAC
> >      engineers) does
> >
> >      not know how to solve the impasse and get the 75 % approval to
> >      either
> >      10.000 or 9.584640 Gbps.
> >
> >      Are these PHYs going to be capable of sending/receiving both at
> >      10.000 and 9.584640 Gbps ? This would appear to contradict the
> >      accepted idea in the HSSG that the future standard should be
> >      either 10 or 9.584640 (exclusive, but not both).
> >
> >      Are we going to define separate PHYs, one for 10.000
> and another
> >      for 9.584640 Gbps ?  Then perhaps it would be better to define
> >      two
> >      separate PARs and working groups, since behind these two
> >      different
> >      clock rates are hidden many additional differences (it is not
> >      just
> >      choosing between short-wave or long-wave laser PHYs).
> >
> >      Jaime
> >
> >      Jaime E. Kardontchik
> >      Micro Linear
> >      San Jose, CA 95131
> >      email: kardontchik.jaime@xxxxxxxxxxx
> >
> >      >
> >      > -----Original Message-----
> >      >From: Booth, Brad [mailto:bbooth@xxxxxxxxxx]
> >      >Sent: Wednesday, July 21, 1999 9:22 PM
> >      >To: HSSG
> >      >Subject: RE: 9.584640
> >      >
> >      >
> >      >
> >      >I really liked the proposal that Kevin Daines put on the
> >      overhead.  One
> >      of
> >      >the reasons that I liked the proposal is that it
> matched what I
> >      pictured in
> >      >my mind. :-)  But there were other technical reasons
> why I liked
> >      it.
> >      The
> >      >proposal for those that missed it was to leave the
> MAC/PLS data
> >      rate at
> >      10.0
> >      >Gb/s, but to have the PHYs determine what data rate was
> >      required.  In
> >      the
> >      >case of a LAN PHY, the data rate would be 10.0
> Gb/s... a direct
> >      match
> >      to the
> >      >MAC/PLS data rate.  In the case of a WAN (or OC-192) PHY, the
> >      data rate
> >
> >      >would be 9.58464 Gb/s and the PHY would obtain that
> data rate by
> >      either
> >      some
> >      >form of flow control or buffering scheme.
> >      >
> >      >I like this because it allows the LAN architectures to remain
> >      cost
> >      effective
> >      >while offering the ability to easily concentrate
> links (i.e. ten
> >      1 GbE
> >      links
> >      >map nicely into one 10 GbE link).  This architecture
> puts a bit
> >      of a
> >      cost
> >      >burden on the WAN PHY, but I think that this still
> results in a
> >      cost
> >      >effective solution for OC-192.  The WAN solution may not be as
> >      low cost
> >      as
> >      >the LAN solution, but show me a Gb/s WAN solution
> today that is
> >      as cost
> >
> >      >effective as a Gb/s LAN solution.
> >      >
> >      >The other part that I like is that the only real difference
> >      between the
> >      WAN
> >      >and LAN solutions in Kevin's proposal is the PHY.  Everything
> >      above the
> >      PHY
> >      >(including interface to PHY) remains relatively
> unchanged.  Yes,
> >      it's
> >      all
> >      >going much faster, but that's an implementation issue, not a
> >      standards
> >      >issue.  At least that's my impression. :-)
> >      >
> >      >Just my 2 cents worth,
> >      >Brad
> >      >
> >      >Brad Booth
> >      >Level One Communications, Austin Design Center
> >      >(512) 407-2135 work
> >      >(512) 589-4438 cell
> >
>