Re: Interface reality check
Steve,
We're beer drinkers not flesh eaters. You're safe in this thread,
honest!
All others,
Keep those opinions coming, please! I have a feeling this will be
a lively discussion in May and the more ideas that get aired now,
the better prepared we'll all be for it.
Ben
Steve Haddock wrote:
>
> Hi Rich, Hi Ben!
>
> New blood? Why would you want new blood? You're doing so well! Or do you
> really just want fresh meat?
>
> OK, I'll chime in. The pictures and the discussion have been great. They
> answered a couple of questions that were nagging me, although these
> questions never came up directly in any reflector message that I saw. Just
> to make sure I'm drawing the right conclusions, these were my questions:
>
> 1) Is it necessary for a PCS/PMD to carry /A/K/R/? I believe the answer is
> no. When this whole issue came up I shared Ben's assumptions that /A/K/R/
> would not be carried across a 64/66 link, but Rich's passion for carrying
> them end-to-end made me wonder whether it was necessary for correct
> operation of XAUI in some case that I was missing. The pictures have
> convinced me that there is no absolute requirement for carrying /A/K/R/
> end-to-end. I believe this is true even if the link is a 8b10b encoded WWDM
> link that uses /A/K/R/ in a similar manner to XAUI. Things will operate
> properly if /A/K/R/ is translated to /I/ and then regenerated as an
> independent /A/K/R/ pattern at each XAUI-WWDM-XAUI interface (although I
> doubt any implementations would actually do it this way).
>
> 2) Is it beneficial for a PCS/PMD to carry /A/K/R/? Rich's point of view
> is that it is simpler if /A/K/R/ does not have to be translated to /I/ at a
> XGXS-to-PCS boundary, but I would argue that simplicity is not the same as
> beneficial. Since a PCS-to-XGXS boundary cannot assume there will be
> /A/K/R/ coming across the link (there may not be a XAUI at the other end),
> it has to generate /A/K/R/ patterns itself. At that point there is no
> benefit to having /A/K/R/ carried across the link.
>
> 3) Is there a disadvantage to carrying /A/K/R/ across a PCS/PMD? The only
> disadvantage that I see is that it consumes contol-code space in the PCS
> encoding scheme. If the control-code space is available, this is a very
> minor disadvantage.
>
> So in the end I'm ambivalent about whether or not /A/K/R/ get carried across
> a PCS/PMD or not, but I do feel rather strongly about how this translates
> into requirements in the specification. What I would propose is:
>
> a) A PCS/PMD is not required to propagate /A/K/R/ that it receives when
> (and if) attached to XAUI.
>
> b) The RS receiver and any PCS receivers shall treat any
> unknown/unrecognized control symbol as an idle when received during the
> Inter-Packet-Gap. Unknown control symbols received in a frame should be
> treated as an error, but between a valid end delimiter and a valid start
> delimiter there is no particular need or benefit to such error checking. An
> over-constrained specification is bad for interoperability and restricts
> degrees of freedom that may become important someday. By the way, encoding
> schemes that can distinguish between truly invalid symbols and
> unknown-but-still-valid control symbols should count invalid symbols as
> errors. This allows detection of poor signal quality on an idle link.
>
> I think it is cleaner if /A/K/R/ is not allowed outside of XGXS boundaries,
> but since I think an RS receiver should be tolerant of any control symbols
> received in an IPG I'd be willing to compromise on allowing an XGXS to
> propagate /A/K/R/ rather than having to translate them to /I/.
>
> I think there is a bigger issue that came out in Rich's pictures: /O/. As I
> said above I'm in favor of permissive receivers, so I don't care if a /O/
> shows up in an IPG and gets treated as an /I/. It is a very different thing
> to say that /O/ must be carried end-to-end across any PCS/PMD, which is
> implied in Rich's pictures. This would mean that every PCS/PMD would have
> to know how to encode /O/, which then means we have to know how many flavors
> of /O/ there are, etc. Who is going to define this? I hope what Rich
> really means is that there may common components between 802.3ae and Fibre
> Channel so there may be parts that know how to translate ordered sets from
> XAUI to 64/66, but there is no requirement for every 802.3ae PCS to know how
> to do this and it is OK for any 802.3ae device that doesn't understand Fibre
> Channel ordered sets to treat them as idles.
>
> Steve
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Saturday, April 01, 2000 12:02 PM
> To: HSSG
> Subject: Re: Interface reality check
>
> Ben,
>
> We're getting much closer. I have comments in the following areas:
>
> Code Space
> ----------
>
> We seem to agree on reserving some code space for future use.
>
> Supporting Fibre Channel in IEEE 802.3ae is not relevant. However, it is
> impossible the overwhelmingly strong market acceptance of gigabit
> interconnects,
> the exponentially growing demand for data transport, and the magical
> convergence
> speed of ~10 Gbps for the LAN, MAN/WAN and SAN.
>
> IEEE 802.3ae has decided that addressing MAN/WAN applications is in its best
> interest. WAN support is written into our PAR and included in our
> objectives. It
> is clear that supporting the MAN/WAN means supporting SONET directly to
> some,
> simply providing Ethernet access to the MAN/WAN to others, and building out
> all
> Ethernet MAN/WANs to still others. I believe that either the IEEE 802.3ae or
> vendors are just going to bet on one of the three MAN/WAN support scenarios.
> My
> own analysis of the strategies and product lines of large companies such as
> Cisco and Nortel as well as VC investments in the past few years clearly
> show
> the billions of dollars are being poured into all three. Getting back to
> code
> space, I believe that 10 GbE needs to be architected in a flexible enough
> manner
> to support MAN/WAN directions.
>
> The Storage Area Network business and applications have been hard to ignore
> in
> 1999 and momentum is still growing. Fibre Channel has already endorsed a
> roadmap
> which includes 10 Gbps and 40 Gbps interfaces for the SAN on a timeline in
> sync
> with MAN/WAN timelines. Many SAN applications also require MAN/WAN
> connectivity
> for applications such as remote backup, disaster recovery, and storage
> sharing
> between remote corporate sites. Some Ethernet vendors have also been eyeing
> the
> SAN space as a huge and easy business opportunity to put under their wing.
> Once
> again, the direction is clear: SANs are here to stay. Getting back to code
> space
> again, I believe that 10 GbE needs to be architected in a flexible enough
> manner
> to support SAN directions.
>
> All these 10 Gbps LAN, MAN/WAN and SAN links need to be sourced somewhere.
> Enter
> the server, whether it be a low-cost high volume or mainframe server. One or
> more 10 Gbps and higher connections will be directly attached to these
> servers
> in the near future, requiring internal 10 Gbps and higher internal I/O
> busses.
> This is where interfaces like InfiniBand(TM) and PCI-XXX enter the picture
> (yeah
> I made PCI-XXX up :-). It just so happens that InfiniBand and 10 GFC and 10
> GbE
> requirements for code space are pretty similar when you get right down to
> it.
>
> "Brown, Ben [BAY:NHBED:DS48]" wrote:
> >
> > Rich,
> >
> > Rich Taborek wrote:
> > >
> > > > Page 1: I agree with everything here except perhaps the /O/.
> > > > I'd like to understand more about why this is needed.
> > >
> > > I've included the /O/, representing "other" in support of other
> standards such
> > > as Fibre Channel and InfiniBand with common parts, for other OAM&P
> functions for
> > > Ethernet WAN access and WAN applications, and for other unforeseen
> extensions to
> > > 10 GbE since I believe that we shouldn't assume that we have all link
> control
> > > functions covered. Both 8B/10B and 64B/66B proposals currently support
> > > additional control codes which may be required to provide /O/ support
> for the
> > > purposes described above.
> >
> > I agree the code space is available and that it should be held
> > reserved. I think a healthy debate is yet to be waged on the virtues
> > or follies of explicitly supporting other standards (Fibre Channel
> > and Infiniband) within "ae".
> >
> > > > Page 2: I agree with everything here except the following:
> > > > This applies for any serial PCS, 64b/66b or other. I think
> > > > this is the picture that I envisioned when I started this
> > > > thread and wat I understand is the picture that Mr. Rick
> > > > Walker is in support of based on his most recent comments.
> > > > The WWDM encoding may be identical to XAUI or may be
> > > > something else completely. Either way, I'd like to
> > > > see this specified with the encodings supported/
> > > > required by RS only. Even XAUI is specified this way.
> > > > XAUI requires /A/K/R/ for a further encoding of the
> > > > IDLE stream but it takes /I/ as input (along with all
> > > > the others /S/T/d/E/RF/BL/). Our debate is where the
> > > > /A/K/R/ gets stripped off after XAUI.
> > >
> > > I'm not sure I understand exactly what you're disagreeing with on page 2
> since
> > > its intention was to show your view: "Serial PHY, 64B/66B PCS, XGXS
> never
> > > forwards /A/K/R/." Page 2 clearly show /A/K/R/ being stripped off and
> translated
> > > back to /I/ by the XGXS adjacent to the PCS in Device A.
> > >
> > > Our debate has also focused on only the Serial PHY and only on 64B/66B
> coding.
> > > I'd like to keep our debate focused on these elements only. I believe
> that this
> > > coding debate is applicable to and independent of other PHY's and
> encodings, but
> > > I'd like to focus on the PHY/PMD we started with, especially since it is
> > > endorsed by a significant cross section of IEEE 802.3ae Task Force
> members.
> > >
> > > Can you please explain your disagreement with page 2 with respect only
> to the
> > > Serial PHY with a 64B/66B PCS.
> >
> > With respect to a Serial PHY using 64b/66b, I am in full agreement
> > with page 2. I was merely pointing out that this can also apply to
> > other serial PCS proposals in addition to 64b/66b and that WWDM is
> > a bit off the beaten path. These discussions probably deserve their
> > own thread.
>
> Yep.
>
> > > > Page 3: I think that this is the picture you've been in
> > > > support of and the one that the current 64b/66b proposal
> > > > describes. I don't agree with this picture.
> > >
> > > If you'll allow me to twist your words: I believe that you agree that
> the
> > > picture accurately represents my previous view of XAUI/XGXS and PCS
> operation
> > > for the Serial LAN PHY with 64B/66B encoding. Your disagreement is with
> this
> > > mode of operation, not the picture. I know it's a minor point, but I am
> trying
> > > to accurately portray our debate in pictures since words are apparently
> not
> > > working.
> >
> > Again, you are absolutely correct. I disagree with this mode
> > of operation. Because this picture represents this mode of
> > operation, I don't particularly like it but my distaste is
> > based solely on the mode of operation that it represents, not
> > the picture itself. I think it is a great picture to describe
> > your previous view of XAUI/XGXS and PCS operation.
>
> Great! that was my intention, to picture what you disagreed with and allow
> others to see the same.
>
> > > > Page 4: A minor twist to page 3.
> > >
> > > Wow! This comment boggles my mind!
> > >
> > > This picture is the heart of the presentation and illustrates a solution
> to
> > > problems exemplified in page 2, call it Ben's picture, and page 3, call
> that one
> > > Rich's picture. I must not have done a good job on the picture in page 4
> or
> > > maybe they all look too similar.
> > >
> > > This page shows control codes being generated by the transmitting RS and
> > > modified by the transmitting XGXS, if present. Control codes are then
> > > transparently transported by the PCS and over the medium. All control
> codes not
> > > specified by 10 GbE are translated to Idles by the RS. The latter
> translation
> > > occurs in a manner analogous to that of the 1000BASE-X PCS Receiver.
> >
> > Again, the picture is a fine one that, I believe, accurately
> > represents your current view of XAUI/XGXS and PCS operation.
> > I guess I should have been more explicit. I'm not against the
> > incremental step that this page shows. This incremental step
> > of having the RS treat everything it doesn't recognize as an
> > /I/ is fine. I merely disagree with the base content that was
> > carried forth from page 3.
>
> Now we're getting to the root of the problem. We already agree that multiple
> control codes must be transported by 64B/66B and the medium. These include
> /S/d/I/E/RF/BL/ and we even agree that there are some good reasons to
> transport
> /O/. I'm looking for the simplest way to support all required and optional
> 10
> GbE sublayers and interfaces in a PMD independent fashion. I would do the
> same
> for an SLP-based PCS for the Serial LAN or WAN PHY, for WWDM based on 8B/10B
> and
> for WWDM based on an alternate PCS. Having the RS Receiver simply treat all
> undefined codes as Idles the simplest scheme I could come up with. This
> scheme
> is capable of supporting all proposed PCS and interface codes assembled in
> any
> combination for the 10 GbE link.
>
> I believe that you'll find that the "base content" that you disagree with
> may be
> different for different PCS and optional interface codes. The scheme
> outlined on
> Page 4 is "base content" independent.
>
> > > > Page 5 & 6: I don't see any difference between these 2 pages.
> > > > I agree with this.
> > >
> > > I included these for completeness. They illustrate the "reverse" or
> Device B to
> > > Device A path analogy to Pages 2 and 3, respectively.
> > >
> > > > Page 7: A minor twist to 6 & 7. Though subtle, I don't like
> > > > this but I could probably be convinced by using the same
> > > > arguement that allows the 1000Base-X receive state machine
> > > > to treat "everything else" as /I/.
> > >
> > > I'm still surprised by your comment on page 4 since Page 7 illustrate
> the
> > > "reverse" or Device B to Device A path analogy to Page 4. Your statement
> that
> > > "to treat "everything else" as /I/" is exactly what I had in mind. I'm
> offering
> > > this as the solution to our debate. I'm open to other solutions which
> can
> > > resolve our debate in a simple manner.
> >
> > As I tried to clean up earlier, I agree that this incremental
> > step is a good one (having the RS treat everything it doesn't
> > recognize as an /I/). I simply disagree with carrying /A/K/R/
> > outside the boundary of the XGXS blocks.
> >
> > The bottom line is that we're still in disagreement with the
> > fundamental aspect of this proposal. The pictures are great,
> > the addition to the RS is great. I simply don't think /A/K/R/
> > should be carried outside the boundaries of the XGXS blocks
> > and you think that it's okay if it does. I don't seem to have
> > changed your mind and you don't seem to have changed mine.
> >
> > I think we could have gotten to this point about a month
> > faster if we were drawing on napkins, sitting in nice comfy
> > chairs drinking Guiness.
>
> No doubt. Thanks for boiling down your real concern though. I believe the
> pictures have helped.
>
> Transporting /A/K/R/ through 64B/66B, SLP, SUPI or any other Serial or WWDM
> PCS
> code, given the other mandatory requirements to transport control codes is
> supported in current proposals (e.g. 64B/66B). It is simple to implement (I
> can
> prove that). I'd like to understand your reasons for not carrying /A/K/R/
> outside the boundary of XGXS blocks? Do you object specifically to the
> actual
> 36-bit encodings of the /A/, /K/ or /R/ columns? Why should these be treated
> any
> differently than a 36-bit encoding for /I/?
>
> Personally, I think we're down to nit-picking. I've offered up a solution to
> get
> away from the nit picking. I'd really like to hear from you and others from
> an
> implementation perspective regarding this solution.
>
> > > > I don't think any of my responses have surprised you. At this
> > > > point in the thread, I think we know where each other stands.
> > > > It would be interesting to hear a few others weigh in on this.
> > > >
> > > > Thanks for the nice pictures. This should make involvement by
> > > > the rest of the group much easier.
> > >
> > > That was the intention. Anyone else out there want to offer their
> opinions?
> >
> > Please, let's get some new blood in on this discussion! I feel
> > like we're in a vacuum.
>
> I agree. We either need more participation, or more Guinness :-)
>
> > Ben
> >
> > --
> > -----------------------------------------
> > 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
> > -----------------------------------------
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> 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
--
-----------------------------------------
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
-----------------------------------------