Re: SUPI<>XAUI
I agree with and support Rich's proposed change to replace the scrambled based
SUPI interface with the 8b10b based XAUI interface. It makes sense to get rid if
an interface that has little support with an interface (XAUI) that is already
specified as an optional interface elsewhere in the standard. It is unfortunate
that at the Tampa Plenary the 802.3 voters rejected the motion to affirm the
motion passed in an earlier 802.3ae session to form an ad hoc committee to further
study Rich's proposed change.
Rich's proposal did just come in under the wire for new ideas to be incorporated
into the standard and deserves to be considered.
Regards,
Larry Rennie
Rich Taborek wrote:
> 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
begin:vcard
n:Rennie;Lawrence
tel;fax:818 880 5193
tel;work:818 880 2720
x-mozilla-html:FALSE
org:National Semiconductor Corporation;Networks Product Group
version:2.1
email;internet:larry.rennie@xxxxxxx
title:Principal Engineer-Enginering Manager
adr;quoted-printable:;;27001 W. Agoura Rd.=0D=0ASuite 210;Calabasas;CA;91301;USA
x-mozilla-cpt:;23232
fn:Lawrence Rennie
end:vcard