Re: Interface reality check
Jonathan,
I like the concepts detailed on pages 2, 5 & 6.
Rich likes the concepts detailed on pages 3, 4 & 7.
The difference: I don't like the idea of carrying the
/A/K/R/ oustide the XGXS boundaries.
Either way the vote goes, I like Rich's latest proposal
of the RS treating unknown but valid signals as /I/. This
matches very closely with the way the 1000Base-X PCS
receiver works and I think this goes along with a very
low reading on your "obnox-o-meter".
Rich, do you see our positions differently?
Ben
Jonathan Thatcher wrote:
>
> Ben,
>
> >From my reading, I believe you and Rich have agreed that you are "on the
> same page."
>
> So that I (and everyone else) don't have to go back through all the various
> notes on Rich's pictures and comb through the discussion for the final
> state, would you mind either 1) confirming that you and Rich are in complete
> agreement that the pictures correctly represent yours and Rich's
> Vulcan-mind-melded consensus or 2) modify the picture and then do 1)?
>
> jonathan
>
> p.s. Oops, just turned into a pumpkin....
>
> > -----Original Message-----
> > From: Brown, Ben [BAY:NHBED:DS48] [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> > Sent: Saturday, April 01, 2000 5:00 PM
> > To: HSSG
> > Subject: 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
> > -----------------------------------------
> >
--
-----------------------------------------
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
-----------------------------------------