Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: What is 802.3ae WAN-PHY?

Rich-san & Osamu-san,

Yes, you are clearly catching on to my question. If I assume that there is a
FC Order Set like structure (one of many options available) to the /ODDD/
then we might have something like: /O;D1;D2;D3/. This would have D1 be an
identifier which is mapped to a specific byte of the SONET overhead (J0, C2,
or G1; see below). D2 and D3 could repeat the same data value for

Depending on the method used, your algorithm (((3 * 3/4)/1530) * 10 Gbps)
will have to be adjusted.

While we have been given some brief tutorials on the path and line overhead
bytes, I do not remember anything about the rules for these bytes. I don't
know if the data in the bytes is kept static unless a specific signal is
required or if one of the bytes might actually be used with a full protocol
of its own.

From the
we have SONET overhead bytes: B1, E1, E2, F1, D1:D12, M1, Z1, Z2 unused and
set to zero.
The following bytes are set to fixed values: A1, A2, Z0, K1, K2, S1, J1 
The following bytes are calculated by the SONET framer: B1, H1, H2, H3, B3
None of these would ever have to be mapped to the /ODDD/.

As best as I can tell, the worst case is that the following 3 bytes would
have to be mapped and transmitted every 250 microseconds: J0, C2, G1

This means we need to send one of these three, roughly, every 100k-bytes (if
I didn't goof my math).

Piece of cake, right? Heck, this could even be done with jumbo frames on

It can't be this easy. What am I missing?


> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Saturday, April 08, 2000 6:41 PM
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: 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:
> 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:
> any code-group
> position in the preceeding code-words. 
> 64B/66B PCS is currently proposed to transport all non error 
> 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):
> 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 
> 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 
> > 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