Re: Interface reality check
Rick:
It doesn't look like 64/66 can be extended to ANSI T1X1 systems.
So how is 64/66 going to extend the header mappings? The T1X1 proposals
relay on the <length><type><crc> to provide other frame and header types
for extended environments. In particular the CRC check allows validation of
the <type> field giving a broad range of format extensions. The header CRC
in ANSI T1X1 formats become essential for the extended header fields used
to address ring networks.
Cheers,
Paul
At 06:48 PM 4/5/00 -0700, Rick Walker wrote:
>
>
>Hi Brad,
>
>> "Booth, Bradley" <bradley.booth@xxxxxxxxx> writes:
>> Taking Rich's slides that he sent out last Friday, I did a couple of
tweaks.
>
>I like it. The only point I would quibble with is having the MAC RS
>generate the /A/K/R/ scrambling because it "reduce[s] EMI on the XGMII
>and XAUI".
>
>XGMII is a byte-wide interface so any scrambling of the IPG codes will
>actually cause *more* EMI rather than less. A static pattern at RS is
>the lowest possible RF energy.
>
>So, I would suggest modifying your proposal such that XGXS generates
>/A/K/R/ when receiving /I/ from MAC A's RS and converts /A/K/R/ back to
>/I/ when delivering it to MAC_B's RS layer.
>
>No one has yet articulated any compelling reason to have the MAC
>burdened with XAUI-specific scrambling. In the absence of XAUI, there
>is no need for /A/K/R/ scrambling. Let XAUI do the scrambling itself,
>and clean up afterwards, putting no extra burden on the MAC.
>
>> The concept is that the /A/, /K/ and /R/ that are used for XAUI are 10-bit
>> symbols. We can make them correspond to /a/, /k/ and /r/ which are their
>> "byte equivalents." I put that in quotes, because all /A/s decode to a
>> single /a/, all /K/s decode to a single /k/ and all /R/s decode to a single
>> /r/. The reverse is not true; /a/ is not encoded to a single /A/ (due to
>> running disparity). This is the same as in 802.3z.
>
>This is perfect.
>
>I see no sense in having separate 64b/66b /K/ and /Kb/ codes. These are
>logically equivalent and should be merged into the same symbol when
>transported across a non 8b/10b link.
>
>> I left the /O/ in, because I think that it might add some good features in
>> the future.
>
>Absolutely.
>
>The current proposal for 64b/66b has 8 general control codes, plus SOP
>and EOP signalled by type bytes. I have no intention of crippling the
>code. My point is entirely about how we standardize the usage of codes.
>
>For example, If we wanted /A/K/R/ to be transparently supported through
>all the CODECs so that it could be used for proprietary signalling
>purposes, then we should clearly state this as an objective. If the
>committee agrees to this need, then it would be fine to reserve some
>control space for proprietary vendor-specific modifications. If this is
>the goal, then it should be clearly stated and put into the "LCD".
>
>That said, I would personally prefer if we did not leave a loophole for
>proprietary implementations.
>
>If there is a serious need for out-of-band signalling, then I wish that
>the relevant parties would educate us about what is needed, and work to
>standardize such signalling. I think a general mechanism can be defined
>without opening up Pandora's box. An example of an attempt to do this
>is Osamu Ishida's XGENIE proposal which uses /O/ codes.
>
>I will be much more willing to vote for a proposal that includes a
>standardized out-of-band signalling system supported across all CODECs,
>rather than a scheme which disparages the idea of out-of-band signalling
>while simultaneously leaving loopholes for proprietary implementations.
>
>> This format would work for, or could be applied to, all the current
>> proposals we have on the table from SLP, SUPI, WWDM, WIS, Serial, MAS/PAM,
>> etc. I tried to keep this at an architectural level, not an implementation
>> level. I believe that this architecture should permit the majority, if not
>> all, of the implementations that get built.
>
>I think this is a great idea.
>
>Best regards,
>--
>Rick Walker
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx