RE: Interface reality check
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
> -----------------------------------------
>