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