Re: SUPI<>XAUI
Ladies and Gentlemen,
Time to vent a little frustration over the events surrounding this issue
at the Tampa meeting. At that meeting I presented a "XAUI as a SUPI
Alternative" proposal to replace a PMA sublayer specific to only the
WWDM WAN PHY with one employing a coding scheme significantly more
prevalent to all PHY's. The presentation can be found at:
http://www.ieee802.org/3/ae/public/nov00/taborek_3_1100.pdf
First of all I'd like to start out by re-iterating that the primary
purpose of this proposal is to simplify the 10GE standard by using
common sublayers and interfaces in multiple PHYs.
Several administrative attempts were made to block the further
development of the proposal including the following:
1) Perogative taken by the 802.3 chair to deem a motion to affirm a
motion by the P802.3ae Task Force to form an ad hoc to further develop
the proposal a technical, rather than procedural issue, thereby
requiring approval of 75% of 802.3 voters. The resultant vote did not
acquire the 75% needed to form the ad hoc. It should be noted that the
P802.3ae Task Force approved a motion to form the ad hoc by more than
75%. I fully understand that the reason given by the chair to decide
that the motion was technical was that the further development of the
proposal involved technical changes in a parallel clause. However, since
no technical change was implied or imminent in the motion in question, I
strongly disagree with the decision to call the motion technical instead
of procedural. It now appears that the 75% criteria applies to most
procedural 802.3 motions as well as technical ones.
2) Reviewing the process of Task Force ad hoc formation, it appears that
it is the chair's perogative to form an ad hoc and that approval by
802.3 voters of 75% or even 50% is not required. It appears that an ad
hoc with significantly greater technical implications to P802.3ae, the
Equalization ad hoc, was approved in New Orleans with no motion in the
Task Force or elsewhere as far as I can tell from my recollection and
formal minutes of that meeting. It appears that the same procedures
should have applied to the formation of the XAUI/SUPI ad hoc. This
applies to both Task Force and 802.3 motions related to this issue. I
believe that the ad hoc should have been authorized by the chair after
the straw poll taken prior to the Task Force motion to formally
authorize the ad hoc.
That said, I will go along with the chair's decisions and the will of
the group. As I see it, I can still achieve the goal of the proposal by
submitting a technical comment against Clause 53 during working group
ballot. The suggested remedy would be additional WAN PMA specifications
in Clause 48. However, I see a few problems with this strategy:
1) I have no interest to go this route alone without strong committee
support. This statement is based on many factors including the apparent
lack of a business case, the possibility of compromising Clause 48
objectives and the inclusion of specifications in Clause 48 which may
never be used. I'll address these one by one:
a) Lack of a business case: A primary reason for making the SUPI<>XAUI
proposal is the lack of interest from all camps in the WWDM WAN PHY.
Four PHY types are proposed in P802.3ae: 1) Serial LAN, 2) Serial WAN,
3) WWDM LAN and 4) WWDM WAN. The fourth PHY, WWDM WAN has the least
support form all parties. It should be clear to the most casual observer
that there is no love lost between WAN proponents and both WWDM and
multimode fiber technologies. The WAN camp strongly and practically
exclusively endorses serial and single-mode only solutions. The WWDM PMD
camp strongly supports LAN only solutions as the data rate and coding
differences between the LAN and WAN requires significantly different
optical specifications and testing considerations. In Tampa, it was made
clear by representatives of top WWDM PMD proponents such as David
Cunningham of Agilent and John Dallesasse of Molex that their focus was
on LAN rates and 8B/10B coding. On the PMA/logic side, I know most if
not all of my competitors/compatriots. Few or none of us have any plans
to supply SUPI chips to the market. However, one would be hard pressed
to find a potential supplier of XAUI chips saying that they would not
support the XAUI extensions I've proposed in taborek_3_1100.pdf from a
technical perspective. Bottom line: There is ZERO business case for the
WWDM WAN PHY if SUPI/Clause 53 is employed. There would be a marginal
business case, at best, if XAUI is employed instead of SUPI. If you
agree with my assessment of no business case for SUPI, then Clause 53
becomes nothing more than a burden to all Task Force members and all
implementers of the Standard which must determine whether to implement
and test it.
b) Compromising Clause 48 objectives: If it is determined that a
business case potentially exists for the WWDM WAN PHY employing an
8B/10B based PMA, the proportion of LAN vs. WAN WWDM PHY's and the
complexity of additions to Clause 48 to support the WAN PMA will
determine whether Clause 48 is compromised as a whole. My gut feel is
that the additions are all digital, and therefore, free. I believe that
a decision to support the WAN PMA in Clause 48 would be warmly received
by logic vendors already working on XAUI devices.
c) SUPI stub: As a logic vendor, I'm going to have to explain to my
customers why SUPI is in the standard and why I'm not building chips for
it. I also have to waste valuable time in the Task Force making sure
SUPI works and doesn't break anything else. It's very hard to strongly
defend something that you don't believe in and know deep down that
nobody else believes in either.
2) Schedule: I made it clear in the proposal that it's timing was late,
but fits well into the P802.3ae schedule. I view this proposal as a
technical change, not a new feature and certainly not a new core
proposal. The cutoff dates for the preceding are:
- Last Technical Change: May 2001
- Last Feature: November 2000
- Last New Core Proposal: July 2000
I view this proposal a being well ahead of the deadline for a
change/consolidation of this magnitude. However, waiting for Working
Group ballot to submit the proposal as a technical comment automatically
includes an artificial delay which I'm not too keen about. I'm
interested in cutting over now, not later.
Once again, "I have no interest to go this route alone without strong
committee support". It appears that I had over 75% support at the Task
Group and then politicking took over. I'll be very happy to do the
technical work and prepare a complete proposal very quickly so vendors
can start implementing early products.
In conclusion, I only see a marginal business case in proceeding with
the SUPI<>XAUI proposal at best. I have very little interest in hearing
from SUPI supporters because of the non-existant business case for it. I
am very interested in feedback on my interpretation and frustration with
the process and I am very interested in a show of support for my "XAUI
as a SUPI Alternative" proposal, primarily offers of help to expedite
the acceptance and completion of this proposal. If none is received, I
will very likely drop support for this proposal.
Best Regards,
Rich
--
"Booth, Bradley" wrote:
>
> Ted,
>
> Just to make sure that the story is clear. XSBI, which is specified in the
> Serial PMA clause (51), is an optional instantiation of the PMA service
> interface. The same PMA service interface is used in the WAN WDM PMA clause
> (53); therefore, XSBI could be used as an optional instantiation. What was
> previously known as SUPI is really an architecture for mapping the PMA
> service interface primitives into WDM PMD service interface primitives.
> There is no interface known as SUPI.
>
> What was offered up at the Tampa meeting was to use a slightly modified
> 8b/10b PCS+PMA (similar to that used in the XGXS to create XAUI) to map from
> the PMA service interface to the WDM PMD service interface. The intent was
> to 8b/10b encode the WIS output (running at 9.95 Gb/s) to achieve a per lane
> data rate that is closer to LAN data rate per lane of 3.125 Gb/s instead of
> ~2.5 Gb/s used in the WAN implementation. If I remember correctly, the
> motion to affirm the creation of an ad hoc to generate this information
> failed.
>
> Cheers,
> Brad
>
> -----Original Message-----
> From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
> Sent: Friday, November 10, 2000 7:39 PM
> To: Ted.Speers@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Subject: Re: SUPI<>XAUI
>
> In a message dated 11/10/00 3:00:36 PM Pacific Standard Time,
> Ted.Speers@xxxxxxxxx writes:
>
> > Seeking clarification on this. In New Orleans, people were very clear
> that
> > SUPI was a PMA and not an external interface. Electricals were deemed
> > irrelevant. The expected external interface to the SUPI PMA would be
> XSBI.
> > The implementation would then be:
> >
> > MAC |<----XGMIII---->| XGXS |<-----XAUI------>| PCS-WIS
> |<-----XSBI---->|
> > SUPI-PMD|<----fiber
> >
>
> The XSBI was always set as the interface for the serial PMA. There was
> never any interface from a 16-wide bus to a 4-wide SUPI or
> any other connection other than a single 10Gb/s serial line. Hope this
> helps.
>
> Justin Chang
> Quake Technologies, Inc.
> 50 Airport Parkway, San Jose, CA. 95110
> Tel: 408-437-7723 email: justin@xxxxxxxxxxxxx
> Fax: 408-437-4923 internet: www.quaketech.com
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com