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

Re: Rate Control & far-end WIS (Re: PMD discussion)




Roy,

I have not been saying XAUI is optical.  My (1) in the previous 
note is considering that XAUI is used for connecting a router/MAC 
packge and AU package via backboard copper wiring.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02588.html

As for (2), my understanding of the left side of Rich's slide #9 
is a completed PHY: it has MAC/PCS/PMA/PMD.  It can communicate 
with another 4WDM LAN-PHY.
http://grouper.ieee.org/groups/802/3/ae/public/may00/taborek_3_0500.pdf

Could help me to understand what is your point?

Regards,
Osamu


At 9:50 PM -0500 00.6.4, Roy Bynum wrote:
> Ishida,
> 
> It was my understanding that XAUI was to be a copper extension, not an optical PHY.  That was part of a major argument for several
> months.  Is this coming around again?
> 
> Thank you,
> Roy Bynum
> 
> 
> ----- Original Message -----
> From: "Seto, Koichiro" <seto@xxxxxxxxxxxxxxxxxxxx>
> To: <ishida@xxxxxxxxxxxxxxxxxxx>; <Tom_Alexander@xxxxxxxxxxxxxx>; <rtaborek@xxxxxxxxxxx>; <praveen@xxxxxxxxxxx>
> Cc: <stds-802-3-hssg@xxxxxxxx>; <Stuart_Robinson@xxxxxxxxxxxxxx>
> Sent: Sunday, June 04, 2000 11:03 AM
> Subject: Re: Rate Control & far-end WIS (Re: PMD discussion)
> 
> 
>> [Date: 06/04/2000  From Seto]
>>
>> Ishida-san,
>>
>> I think your point#2 is very valid especially for the cases like attached.
>>
>> Also, I feel the need for link confirmation taking place right before the
>>  link establishment.  There is no way to tell the link partner is
>> recognizing the link in 10GbE at this time.  Your proposing scheme would
>> serve for this purpose as well.
>>
>> Seto
>>
>> >
>> > Tom, Rich, Praveen,
>> >
>> > I think we had better separate the local Rate Control from
>> > the far-end WIS implementation shown in Rich's slide #9.
>> > http://grouper.ieee.org/groups/802/3/ae/public/may00/taborek_3_0500.pdf
>> >
>> > In summary;
>> >  (1) How does MAC recognize locally whether he is WAN-PHY or LAN-PHY?
>> >       - I like to use station management (STA) register.
>> >
>> >  (2) If we implement far-end WIS, do we need auto-negotiation?
>> >       - No, but we will need 'local' auto-configuration.
>> >
>> > Note that I have assumed that 802.3ae adopt the Shimon Muller's
>> > Open-Loop Control for the MAC rate down to 9.29 Gb/s.(Not the bit rate.)
>> > http://grouper.ieee.org/groups/802/3/ae/public/may00/muller_1_0500.pdf
>> >
>> >
>> > (1)How does MAC recognize locally whether he is WAN-PHY or LAN-PHY?
>> >
>> > Assuming that we have optional XAUI/XGXS, 10GbE router port
>> > could be implemented in separated two parts: a router/MAC
>> > package and an Attachement Unit (AU).  The latter may be a
>> > slot-in package or daughter card.  In this case, MAC should
>> > recognize whether his AU is LAN-PHY or WAN-PHY.  The STA
>> > register would be the promising candidate for this purpose.
>> > I don't think manual setting at each AU installation is less
>> > troublesome than defining/using a register bit for this auto
>> > configuration.
>> >
>> > In my sense, this auto configuration is far from 'negotiation'.
>> > MAC will check the register bit when he recognize that the
>> > AU is newly installed.  No timing issue.  No acknowledgement.
>> > I think this STA register bit is extremely useful and worth
>> > for the standard.
>> >
>> > (2) If we implement far-end WIS, do we need auto-negotiation?
>> >
>> > No, I don't think so.  We can use similar 'auto-configuration'
>> > mechanism.   LSS provides the Layer-1 information reporting
>> > from far-end STA to local STA, so it could send the far-end
>> > 'WIS' existence or a register bit to the local STA periodically
>> > by using Link Status [r] together with Remote Fault and Break Link.
>> > http://grouper.ieee.org/groups/802/3/ae/public/may00/ishida_1_0500.pdf
>> > I don't think this is WAN mode 'negotiation'; it's still just a
>> > reporting mechanism.  No timing/speed issue here; always
>> > advertising the same bit status.
>> >
>> > In this far-end WIS implementation,  the local MAC should recognize
>> > the 'far-end AU/PHY installation' event to initiate the auto-
>> > configuration of his local MAC rate.  Every time the Link is
>> > initialized, MAC had better check his local STA register bit
>> > that is reflecting the far-end WIS existence.
>> >
>> > In short, if the community reaches the consensus not to prohibit
>> > anyone from implementing far-end WIS, LSS could provide the
>> > practical solution without adding any control codes.
>> >
>> > Best Regards,
>> > Osamu
>> >
>> > At 03:59 00/06/03 -0700, Richard Taborek wrote:
>> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02587.html
>> > > Tom Alexander wrote:
>> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02568.html
>> > > >   - the 802.3ae objectives do not provide for any form of
>> > > >     autonegotiation over the link. The proposed LSS does
>> > > >     not include speed negotiations, nor is it likely to
>> > > >     be able to do so with current coding schemes.
>> > >
>> > > WAN mode would be configured by SMT in the same manner as other
>> > > options such as flow control, etc.
>> > >
>> > > The primary reason for the committees rejection of Auto-Negotiation
>> > > at 10 Gbps is that the preferred mode of link management is to
>> > > configure a link and have the link come up in the same mode after a
>> > > power event or other disturbance.  There is no apparent benefit in
>> > > having a 10 GbE backbone negotiate down to 1 Gbps on its own accord
>> > > like a modem.
>> > >
>> > > LSS can easily accommodate WAN mode negotiation. I don't believe that
>>
>> > > we have any speeds to negotiate.
>> >
>> > At 19:19 00/06/02 -0700, Praveen Kumar wrote:
>> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02583.html
>> > > In summary, I don't see why parking the WIS on the far end will not
>> > > work.  That being said, Iam not sure either, about whether there
>> > > are enough benefits in allowing this to be a part of the standard
>> > > (it sure does cause some confusion).
>> >
>> >
>> >
>> > ---------------------------------------
>> > Osamu Ishida,ishida@xxxxxxxxxxxxxxxxxxx
>> > NTT Network Innovation Laboratories
>> > TEL:+81-468-59-3263 FAX:+81-468-55-1282
>> > ---------------------------------------
>> >
>>


-----------------------------------------
Osamu ISHIDA
NTT Network Innovation Laboratories
TEL +81-468-59-3263  FAX +81-468-55-1282