Re: What is 802.3ae WAN-PHY?
Jonathan,
It's possible, it's beyond cool, and the details and mapping for the data flow
have already been proposed in various HSSG presentations as well as over this
reflector. Please allow me to summarize the mapping and data flow below:
The delimiter and control character set (alphabet, if you will) proposed for the
Reconciliation sublayer (RS) is:
- Idle /I/
- SOP /S/
- EOP /T/
- Error /E/
- Data /D/
We appear to have converged on four octet values for use as code "words" by
noting the 36-bit XGMII, 4-lane XAUI, 4-lane WWDM, 4-lane SUPI, 4-lane SLP as a
PMA interface, etc. Four octet control words also map well to proposed
delimiters, 64B/66B transmission code, a 312.5 MHz processing rate for 32-bit
information, Fibre Channel ordered-sets, XGENIE ordered-sets, etc. Current RS
proposals map the five required RS control characters into specific code-words.
The complete proposed code-word set based upon the five required RS control
characters is:
- SDDD, DDDD, TIII, DTII, DDTI, DDDT, IIII, E in any code-group position in the
preceding code-words.
All optional interfaces including XGMII and XAUI/XGXS, all sublayers including
the PCS and PMA sublayers as well as the medium must be capable of somewhat
faithfully transporting all of the above codes. I say somewhat, because of the
following transmission code peculiarities:
XAUI/XGXS as well as the WWDM PCS must convert /I/ to /A/K/R/ to efficiently
handle synchronization, skew, EMI, clock tolerance compensation, etc. As a
result, XAUI transports three code-words in place of /IIII/ and translates of
EOP words since /I/'s are not valid 8B/10B code-groups. The complete set of
code-words transported by XAUI/XGXS to support required RS codes is:
- SDDD, DDDD, TKKK, DTKK, DDTK, DDDT, AAAA, KKKK, RRRR, E in any code-group
position in the preceeding code-words.
64B/66B PCS is currently proposed to transport all non error RS and XAUI/XGXS
code-words transparently, but has problems with /E/ codes due to limitations in
code space caused by the number of possible locations of one or mode /E/ codes
in any code-word. As simple compromise is to generate 64B/66B /E/ "frames"
whenever an error is detected or must be forced into the information stream.
Like the replacement of /I/ by /A/K/R/, this process does not affect the
contents of the information being transported between RS peers. I believe that
the following list represents the information content of all 64B/66B frames to
support RS codes. Note that Z may represent (I,E,A,K or R):
- SDDD/DDDD, ZZZZ/DDDD, DDDD/DDDD, ZZZZ/ZZZZ, TZZZ/ZZZZ, DTZZ/ZZZZ, DDTZ/ZZZZ,
DDDT/ZZZZ, DDDD/TZZZ/, DDDD/DTZZ, DDDD/DDTZ, DDDD/DDDT
Now... You're asking about the mapping and data flow to transport OAM&P like
information between peer PCS elements and possibly peer RS elements (which
requires that the same information also be transported between peer PCS
elements).
In either case, additional OAM&P code-words must be defined. Due to two factors:
1) Simplicity of transport Logic.
2) Support of Fibre Channel and InfiniBand control-words;
I propose, as does Mr. Osamu Ishida for XGENIE, and Mr. Rick Walker for 64B/66B
in recent reflector notes, that OAM&P code-words for XGENIE be transported by
code-words with the following format: ODDD. This single code-word minimal
addition should have enough flexibility to meet the needs the link management
needs of all envisioned protocols.
I further propose that the code-word /ODDD/ be supported in a transmit and
receive capacity by the RS in order that it be independent of the multiple
proposed PCS sublayers as well as proposed optional XGMII and XGXS/XAUI
interfaces.
/ODDD/ code-words may generated at the request of Station Management at the RS
during the IPG only and with a frequency no greater than 1/4 to 1/2 the IPG
density (1/2 may be too much, I have to think about this some more. 1/4 should
definitely be OK). I believe that a 1/4 rate corresponds to management data
throughput of a minimum of ((3 * 3/4)/1530) * 10 Gbps ~= 15 Kbps or .15% of
available link bandwidth for Ethernet OAM&P functions. These functions can
include Remote Fault and Break Link signaling.
The RS receiver would trap all control-words for use by Station Management and
forward only MAC PLS service primitives to the MAC.
/ODDD/ code-words may be inserted/removed from the IPG stream by Station
Management anywhere along an Ethernet Link that Station Management is present. I
believe that a "conservation of IPG bytes" rule is appropriate since I don't
envision mixing OAM&P functions with clock tolerance compensation functions.
Inserted OAM&P code-words must replace removed ones or ensure that the maximum
frequency of OAM&P code-words is not exceeded. Deleted OAM&P code-words must be
replaced by Idles or replacement OAM&P code-words.
The alternative of allocating specific code-words and possibly multiple formats
for OAM&P signaling would seem to complicate the specification of RS operation
and PCS encodings.
I'd be honored to work with others to present complete details for supporting
Ethernet OAM&P transport which is PCS, interface and LAN/WAN independent during
the May interim meeting in Ottawa. If you're interested in helping out or simply
endorsing this direction, please send me a private email to keep reflector
traffic down.
Best Regards,
Rich
--
Jonathan Thatcher wrote:
>
> The approach that Osamu is pursuing is interesting to me due the potential
> I foresee in being able to concatenate any number of LAN-PHY or WAN-PHY
> segments together in any order and still manage these with using existing
> tools nearly transparently. If this is possible, it would be beyond cool.
>
> I assume the following from what I have seen thus far:
> 1. To adopt this might not require 802.3ae to write a new set of
> line/path/etc management primitives.
> 2. A direct mapping would allow the "WAN" and the "LAN" systems to link in
> a more direct way at, effectively, a lower level.
> 3. It permits greater flexibility in where we might choose to architect the
> SONET framer in order to optimize the solution. It might even permit
> multiple instantiations.
>
> I am still curious about the details for the mapping and the data flow.
>
> jonathan
-------------------------------------------------------
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