Re: XAUI and 64b/66b
Ben,
I believe that we both realize that the root issue is what Idle pattern goes
into a 64B/66B frame. If you disagree with this, you can probably discard the
rest of this note, but if you agree, read on.
"Brown, Ben [BAY:NHBED:DS48]" wrote:
>
> Rich,
>
> It sounds like we intend to agree to disagree (or at least I do).
>
> Rich Taborek wrote:
> >
> > Walt, et. al.
> >
> > Jonathan and I just spent well over an hour on the phone discussing various
> > points of view on this issue. I'm sensing that one can view this issue form
> > verious perspectives including architectural purity, actual implementations,
> > standards documentation to ensure interoperability but not restrict
> > implementations, etc.
> >
> > First of all, let me try to succinctly state the issue: Ben is asking why
> > 64B/66B coding needs to map XGXS codes instead of simply mapping RS codes.
> >
> > I don't believe that it helps at all for any architectural descriptions or
> > standards documentation to describe the interface on the PCS side of the the
> > XGXS as the XGMII. I say this because I believe that we're getting completely
> > caught up in interfaces to interfaces. Both architecturally and with respect to
> > an implementation, the proposed Reconciliation Sublayer, not the XGMII,
> > generates the control codes associated with the MAC data which is to be passed
> > to the PCS. The proposed XGMII is 36 bits wide plus one clock signal in each
> > direction. If the optional XGMII extender is employed, 8B/10B encoding converts
> > RS codes to XGXS codes. These codes are transported across XAUI to the remote
> > XGXS. The XGMII itself is optional.
>
> Just as you state, the XGMII is optional. Therefore any extension of
> the XGMII is, too. To go further, any control codes supported by that
> optional extension are optional. That leaves us only with the control
> codes of the RS. I understand and support that implementations may
> choose to perform this extension and control code mapping. I just
> don't agree with forcing this control code mapping by specifying to
> it in the standard. Here again, we simply disagree.
It's the "extension of the XGMII" that I strongly disagree with. My
interpretation of extension is that it "goes farther" than the original. Your
understanding seems to imply that the XGMII is REQUIRED in order to extend it.
Mine is that XAUI/XGXS can either EXTEND or REPLACE the XGMII. As always, I'm
considering both the architecture AND product implementation. I've always
considered it silly to focus on only one or the other.
If you would bear with me for the moment, I'd like to use an "extension cord"
analogy. Let's say you're working in the yard with some power tool and are using
one of those brown, 15', 20 AWG, triple-tap extension cords and you need to go
25'. You go back to the shed and pick up an orange, 50', 14 AWG, grounded power
cord. You have several choices:
1) Try plugging the 50' cord into the 15' one by taking another trip back to the
shed (cursing) and getting either a 3-prong adapter or some sharp instrument to
modify the end of the triple-tap; or
2) Removing the 15' cord at the source and plugging the 50' cord in at the
source.
I'd bet that most folks would opt for (1), but (2) is clearly safer, more
reliable. It's also the ONLY commercially recommended configuration.
I think this brings us back to the control code mapping issue.
> > At this point it is important to note that:
> >
> > 1) There is no architectural or implementation value in reverse-translating the
> > XGXS code to that of the RS for any PCS including Serial, WWDM, Parallel Optics
> > or MultiLevel;
>
> It sounds like your opinion is that for implementations
> which use XAUI, it is a pain to translate back to RS
> control codes. I might agree with that. However, for
> implementations that don't use XAUI, it is more of a
> pain to make that translation. Another disagreement?
Yes, I disagree. The point of disagreement is that it is no more pain, overhead,
etc. to have the Serial PCS generate /A/K/R/ instead of just /I/ from the RS.
There are already proposals from others to transport codes over 64B/66B which
may or may not come from the RS. One of these is in support of pure
OpticalCrossconnect from NTT: See the proposal from Mr. Osamu Ishida:
http://grouper.ieee.org/groups/802/3/ae/public/mar00/ishida_1_0300.pdf. Other
requirements come from Fibre Channel and InfiniBand but I realize that these are
NOT Ethernet. I will add though that the transport of FC SAN and InfiniBand data
over the WAN in exactly the same way as Ethernet is something that I know your
company and most others in IEEE 802.3 is interested in.
I'd like to work with you to define the translation which provide the largest
possible market for 10 GbE equipment.
> > 2) For the sake of architectural purity, there is reason to place an XGMI
> > Interface between the XGXS and PCS. For implementation sake, XAUI extends the
> > XGMII by attaching to the end of the XGMII not in the middle of it.
>
> Definitely a disagreement (attaching to the end and not sitting
> in the middle, I mean).
I agree that we disagree. There is no XGMII requirement for XAUI/XGXS as I
understand it. Calling XAUI/XGXS an "XGMII extender" is meaningless from an
architecture or implementation perspective. Therefore, I consider it to be only
politically motivated. Sitting in the middle implies that TWO XGMII interfaces
are REQUIRED to support XAUI/XGXS. This is nothing short of ludicrous as a
REQUIREMENT. I STRONGLY DISAGREE.
> > 3) The XGMII is optional, the RS is not. If an implementation chooses to
> > implement XAUI and not the XGMII, should the architecture and standard dictate
> > that XGXS codes be reverse-translated to RS codes? If so, should there be a
> > second Reconciliation sublayer between the XGXS and RS? See how silly this gets?
>
> The picture does tend to get confusing. However, if the XAUI
> is an extension of the XGMII, and the XGMII isn't "there" how
> can a XAUI be "there"? This does seem silly. However,
> architecturally, I think these layers are required to avoid
> a certain amount of confusion.
This is simple. The XGMII is optional. XAUI/XGXS is optional. They must both be
shown as architectural layers/interfaces in the IEEE 802.3ae Layer Diagram
proposed by Mr. Brad Booth:
http://grouper.ieee.org/groups/802/3/ae/public/mar00/booth_1_0300.pdf, slide 10.
The XGMII is shown on top since this make the most sense from an implementation
perspective. Either, both or neither may be present. The stack still needs to
work. Think of the XGXS being integrated into the MAC/RS with no XGMII. This is
a very reasonable high port density implementation.
> A PCS needs to use the same control codes as the RS. If there
> is an XGMII between them, cool. If a XAUI extends that XGMII,
> even cooler. For parallel/CWDM if the PCS is identical to the
> RS side XGXS, then implementations would certainly be unlikely
> to go back and forth with control codes. However, the picture
> should be clear, silly or not. Another definite disagreement.
Most definitely a disagreement! The control codes for GbE at the RS and PCS and
PMD are all SIGNIFICANTLY different. However, no information is lost going down
to the lowest layers. Some information required by the lowest layers is not
passed up to the RS.
For Parallel/WWDM the RS Idle coding is /I/, whereas the PCS Idle coding is
/A/K/R/. I consider these different control codes. Do you consider them to be
the same?
There is no requirement, historical, architectural, or otherwise for "A PCS
needs to use the same control codes as the RS."
For multilevel signaling control of laser linearity, I've proposed using
multiple control codes mapped to each idle and translating back. I consider
these code to architecturally be defined in the PCS. They would not be passed up
to the RS. There is no need to do so.
It is correct to state that RS control codes must be transported by the PCS. It
is generally not architecturally prudent to REQUIRE that all lower layers
transport exactly the same data and control information. It is usually the
control information that differs going up and down the stack. This is the
purpose of defining layers in the first place.
> > 4) If indeed you still believe that the Serial PCS should reverse-translated
> > XGXS codes (/A/K/R/'s) into RS codes (/I/'s) and the stream gets all the way to
> > the optional Remote XGXS adjacent to the Remote PCS, this XGXS must regenerate
> > the XGXS codes to support XAUI. It's much simpler to not do thia translation
> > twice.
>
> I would argue that implementations which do not use XAUI
> won't have to do it at all. Another disagreement.
No. Here we agree. The operative word is "implementation". So long as an
implementation can properly translate its received control codes properly to
pass to the RS it would be deemed compliant.
> > At this point, I'd like to ask some questions?
> >
> > What's the big deal about having the Serial PCS, and specifically 64B/66B
> > transport (/A/K/R/) instead of (/I/)?
> >
> > What is the achitecture, documentation or implementation or other useful reason
> > for requiring a re-translation of XGXS code back to RS codes at the PCS?
> >
> > What is the achitecture, documentation or implementation or other useful reason
> > for requiring an XGMII between the XGXS and PCS?
>
> I simply find it ackward to define a serial PCS encoding as using
> control codes based on an optional interface. If the XAUI becomes
> mandatory, then this makes sense. While the XAUI remains optional,
> I simply can't support this. Obviously, a major disagreement.
XAUI/XGXS is also optional for Parallel/WWDM. What are your thoughts on the PCS
coding for Parallel/WWDM in the presence or absence of XAUI/XGXS?
It's simply no different to specify the same RS to PCS translation for all PHYs
in the same manner, yielding a PHY independent RS, XGMII and XAUI/XGXS. It may
seem awkward, but the cost is nil.
Best Regards,
Rich
--
> Ben
>
> --
> -----------------------------------------
> Benjamin Brown
> Router Products Division
> Nortel Networks
> 1 Bedford Farms,
> Kilton Road
> Bedford, NH 03110
> 603-629-3027 - Work
> 603-629-3070 - 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