Re: Interface reality check
Ben,
I agree with you that any signaling across a "regenerator" which would require
the signaling of control information beyond a normal Idle should not utilize a
re-ordering of /A/K/R/, whether or not this signaling is performed over XAUI.
The proposed Reconciliation Sublayer is defined as an encoded interface
supporting at least the following data and control information:
Start of Packet /S/
Data /D/
End of Packet /T/
Idle /I/
Error /E/
The following additional control codes have been included in other proposals:
Busy Sync /KB/
Busy Idle /RB/
Remote Fault /RF/ (used in Fast/Gigabit Ethernet)
Break Link /BL/ (used in Fast/Gigabit Ethernet)
Other /O/ (reserved or for other standards, OAM&P, etc.)
Multiple control codes, analagous to a "code-alphabet" are specified.
A very specific dictionary of "code-words" is specified for transmission across
various 10 GbE interfaces. These interfaces include the optional XGMII, optional
XAUI and the medium
Required code-words for transmission include the following:
SDDD, DDDD, TIII, DTII, DDTI, DDDT, IIII, E in any position
XAUI requires the transmission and reception of three additional code-words and
the translation of End-of-Packet words since /I/'s are not valid 8B/10B
code-groups
AAAA, KKKK, RRRR, TKKK, DTKK, DDTK
Additional code-words defined for transmission and reception should follow the
same basic rules. The obvious principal rule is that code-words should be
defined as being four code-groups in length for simple recognition. In addition,
standard coding practices such as good hamming distance should be observed.
I believe that we have enough information about 10 GbE requirements to allocate
an adequate amount of reserved control code space to meet all current and future
control requirmements.
Ordered-Sets of the format ODDD, currently proposed for XGenie, Fibre Channel
and InfiniBand are an example of a simple and elegant means of meeting these
requirements. All other code-words may be treated as Idles by the RS receiver.
Best Regards,
Rich
--
"Brown, Ben [BAY:NHBED:DS48]" wrote:
>
> Osamu,
>
> 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.
>
> 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 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.
>
> 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
> -----------------------------------------
-------------------------------------------------------
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