Re: Interface reality check
Ben,
Thank you for your understanding.
I would like to add one more comment to my previous explanations;
these advantages are not limited to a regenerator, but also be
applicable to an attachment unit alone that may be optionally
defined by the standard.
Best Regards,
Osamu
At 10:38 AM -0400 00.4.3, Brown, Ben [BAY:NHBED:DS48] wrote:
> Osamu,
>
> I understand now. Yes, I agree that this feature would be
> useful in a regenerator such as you've described. Is it worth
> the effort? This decision will come from the group at large.
>
> Ben
>
> Osamu ISHIDA wrote:
>>
>> Ben,
>>
>> Sorry for my too short explanation. I'll make it clear bellow.
>>
>> At 10:41 PM -0400 00.4.2, Brown, Ben [BAY:NHBED:DS48] wrote:
>> > Does the regenerator you describe look something like this?
>> >
>> > PMD -> PMA -> PCS -> XGXS -> XAUI -> XGXS -> PCS -> PMA -> PMD
>> >
>> > I'm not sure this would be a device specified in the standard
>> > even though it uses components defined by the standard. However,
>> > let me see if I can follow through with your thought process.
>>
>> Yes, you have drawn my regenerator perfectly. I do not care this
>> regenerator would be a standard device or not, since I think it
>> will work well simply by using components defined by the standard.
>>
>> > In my opinion, the /A/K/R/ only exists between/within the
>> > XGXS boundaries. It is used for alignment, jitter, etc., across
>> > the 4-lane XAUI and has a useful purpose there. Others are of
>> > the opinion that /A/K/R/ can be carried past these boundaries
>> > with the only detrimental affect being the loss of PCS coding
>> > space.
>>
>> I think I have understood both sides cleary. My opinion is /A/K/R/
>> transparency beyond the boundaries has a little practical advantages
>> that deserve the negligible loss of PCS control code space in 64/66.
>>
>> > I think your message is referring to yet another "future idle-
>> > sequence". I presume this means additional codes beyond /A/K/R/
>> > as opposed to simply a re-ordering of these same codes. Given
>> > XAUI's randomness in the order of /A/K/R/, re-ordering these
>> > same codes would not be obvious. So, the new codes required by
>> > your "future idle-sequence" would require additional code space
>> > and, in particular, would need to be defined during the standard
>> > specification phase so the PCS would know what these codes are.
>> > To get these codes defined during the specification phase of
>> > the standard, you would not be making this a "future idle-
>> > sequence" but another "present idle-sequence" and presumably,
>> > this one would exist to fulfill a particular purpose that /A/K/R/
>> > couldn't fill.
>>
>> No. Here I just consider a re-ordering of /A/K/R/.
>>
>> First, I am concered that Fibre Channel may adopt different rules for
>> re-ordering these /A/K/R/. FC may have more powerful randomization to
>> reduce EMI a bit further. In this case the regenerator can enjoy this
>> EMI reduction if his XGXS has /A/K/R/ transparency. If not, the
>> regenerator only follows the 802.3ae randomization rule and can not
>> enjoy further EMI reduction.
>>
>> Second, if we have /A/K/R/ transparency, we can debug the regenerator
>> at XAUI by simply inserting fixed (non-randomized) /A/K/R/ pattern into
>> the PMD. If we don't have /A/K/R/ transparency, inserting /I/ into the
>> PMD yields randomized /A/K/R/ on XAUI and hence we can not observe fixed
>> pattern there; this may be a little hard to maintenance.
>>
>> I agree that these advantages are far from dramatic. However, in my
>> opinion, these are enough to deserve the loss of PCS coding space if it
>> is far from running out as Rich has pointed out.
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01924.html
>>
>> I hope this helps you and Rich to wrap up your brilliant discussions.
>>
>> Best Regards,
>> Osamu
>>
>> > Allowing the receive state machines to treat unknown but valid
>> > codes as idles is one thing but I don't know how to future proof
>> > the transmit machines.
>> >
>> > Have I mis-understood you? Can you please shed more light on
>> > something I'm missing?
>> >
>> > Thanks,
>> > Ben
>> >
>> > Osamu ISHIDA wrote:
>> > >
>> > > Dear Ben and Rich,
>> > >
>> > > At 8:33 AM -0500 00.4.1, Brown, Ben [BAY:NHBED:DS48] wrote:
>> > > > Please, let's get some new blood in on this discussion! I feel
>> > > > like we're in a vacuum.
>> > >
>> > > I would like to add another side dish for your Guinness;
>> > > this is a bit reinforcement for XGXS to propagate /A/K/R/ rather
>> > > than having to translate them to /I/.
>> > >
>> > > I have guessed the /A/K/R/ randomization in Rich's mail to work
>> > > pretty well for EMI reduction, but still would like to reserve my
>> > > last one cent to future idle-sequence up-grade by other standard
>> > > such as fibre channel. Also another peculiar application
>> > > may utilize the /A/K/R/ sequence itself for some other purposes,
>> > > such as field maintenance debugging tool hinted by Mr. Edward Chang.
>> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg01916.html
>> > >
>> > > Once we carriers invest in a 10 Gigabit Regenerator that is a
>> > > pair of two Attachment Units connected back to back with XAUI
>> > > backboard interface, we hope the regenerator can enjoy the future
>> > > up-grade benefits and can carry another idle sequences without any
>> > > field upgrade operation.
>> > >
>> > > If XGXS on the regenerator does not propagate /A/K/R/ or any other
>> > > interpacket gap sequences as it is, our investment may lose strong
>> > > support of potential automatic field upgradability/interoperability.
>> > >
>> > > Cheers,
>> > > Osamu
>> > >
>> > > ---------------------------------------
>> > > Osamu Ishida
>> > > NTT Network Innovation Laboratories
>> > > TEL:+81-468-59-3263 FAX:+81-468-55-1282
>> > > ---------------------------------------
>
>
> --
> -----------------------------------------
> Benjamin Brown
> Router Products Division
> Nortel Networks
> 1 Bedford Farms,
> Kilton Road
> Bedford, NH 03110
> 603-629-3027 - Work
> 603-624-4382 - Fax
> 603-798-4115 - Home
> bebrown@xxxxxxxxxxxxxxxxxx
> -----------------------------------------