Re: Interface reality check
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
-----------------------------------------