Re: Interface reality check
Ben,
Mr. Don Alderrou and I have been discussing this issue today and believe that we
have come up with a solution which involves a change to the Reconciliation
Sublayer. I need to draw some pictures and will have to do those tonight.
However, I'll offer a quick explanation in the mean time.
The issue is not whether XAUI encodings are required for 64B/66B, the issue is
whether either the MAC needs to signal the PHY with anything other than Idles or
the PHY itself needs to signal over the medium.
I completely forgot about the obvious case of ERROR, where the MAC transmitter
or the PHY at any point in the link needs to replace a data or control code with
an ERROR code. In order to support this proposed function, 64B/66B must
transport /E/ codes in addition to /I/ codes across the medium.
Note that Gigabit Ethernet also signals Break Link and Remote Fault through the
use of Config words, which are essentially a control encoding different than the
GbE idle stream. Several folks including Mr. Howard Frazier and myself have
already alluded to the benefit and compatibility of supporting Break Link and
Remote Fault for 10 GbE.
This makes for a potential requirement to signal at least three control codes
besides /I/, /T/, /S/ and /D/ across 64B/66B and the medium. A further
requirement is to support the transport of these codes through the optional
instantiations of the PCS Service interface.
One way I'll propose to do this cleanly is to have the RS receiver treat /A/K/R/
the same as /I/. In fact, all codes other than /T/, /S/, /D/ and /E/ could be
treated as /I/ by the RS receiver until those other codes are defined by 10 GbE.
No translations by the PCS, including 64B/66B, would be necessary.
Whaddya think?
--
Best Regards,
Rich
"Brown, Ben [BAY:NHBED:DS48]" wrote:
>
> Rich,
>
> Okay, where was I? Ah, yes, my original question on this thread
> was to ask if the XAUI encodings were required for the 64b/66b
> PCS. You stated that they were not required directly but there
> were several reasons why you'd want them. These were listed in
> your last mail quite succinctly.
>
> Rich Taborek wrote:
> > Once again, in a recent communiqué between Mr. Ben
> > Brown and myself, I pointed out several reasons to transport non idle codes
> > across the medium. These reasons are typical and atypical and include the
> > following:
> >
> > a) Support of "Remote Fault" and "Break Link" capabilities to enable timely
> > failover of a broken link to an alternate link, if available. This capability
> > exists at other Ethernet speeds and is an extremely useful link management
> > function. This functionality can be considered a basic OAM&P function;
> >
> > b) Support of Open Fibre Control protocols which may enable longer link support
> > distances resulting from the ability to safely increase transmitted optical
> > power;
> >
> > c) Support of Layer 1 signaling for Optical Cross-Connects and management. This
> > item essentially provides native Ethernet WAN links with the equivalent of OAM&P
> > for SONET. It is clearly complimentary to HSSG objectives to support the WAN and
> > 40+ km links. Note that I have raised serious technical questions about the
> > whether the WAN PHY is capable of cost effectively meet the requirements of
> > Ethernet device and equipment design based on the requirement to perform SONET
> > re-framing whenever clock tolerance compensation is required. This is not the
> > case with the LAN PHY. A consequence of this issue is that the WAN PHY OAM&P
> > requirement satisfied by SONET framing may need to be accommodated instead by
> > the LAN PHY in a manner similar to that described by this item;
> >
> > d) A desire for common components with Fiber Channel, InfiniBand, etc.
> > Basically, Ordered-Sets may be supported as an optional Layer 1 signaling method
> > for FC, InfiniBand and other protocols and not affect 10 GbE. If and when a
> > layer 1 signaling function is required for 10 GbE it can simply be enables
> > without "re-spinning" components. Transparent support for such functions would
> > be tantamount to treating unrecognized control codes as Idles as is currently
> > the case for the 1 Gigabit Ethernet PCS Receive state machine.
> >
> > Support of any of the above items requires the transport of non Idle codes
> > across the medium. This support is already provides in the existing RS, XGMII,
> > XAUI/XGXS and 64B/66B proposals. I propose the that these functions be
> > maintained and exploited only to the extent to provide the level of support
> > required to provide a robust 10 GbE architecture for the LAN, MAN and WAN.
> >
>
> I don't think that it is necessary for the serial PCS, be it
> 64b/66b or something else, to carry the XAUI form of IDLE
> encoding (/A/K/R/...).
>
> I think there are probably reasons, such as some of the ones
> above that you mention, that a PCS can carry more than just
> the XGMII encodings. I'm not sure I agree with all of your
> reasons.
>
> For background, I went back and looked at the clause 36 state
> machines. The 1000Base-X receive state machine does indeed ignore
> code-groups other than the actual /I1/ and /I2/, treating them as
> if they were /I1/ or /I2/ but the transmit state machine is only
> allowed to send /I1/ and /I2/. The transmit state machine actually
> had it easy because between packets it could use TX_EN and TX_ER
> to decide what was to be transmitted. While TX_EN was false, the
> state machine would send /I/. When it was true, it would send /S/
> (after aligning to even/odd), perhaps followed by a /V/ if TX_ER
> was also true for that first clock.
>
> With the new XGMII encodings, the conditions for leaving the
> IDLE state will be more complex. If we use the XAUI encodings
> it will be downright confusing. I think we need to look very
> closely at each reason we want the PCS to send something other
> than /I/ when it is between packets. For everything we add, the
> state machine becomes exponentially more difficult and confusing.
>
> 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
> -----------------------------------------
-------------------------------------------------------
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