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
redundancy.
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
http://grouper.ieee.org/groups/802/3/ae/public/mar00/figueira_1_0300.pdf
proposal,
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
steroids!
It can't be this easy. What am I missing?
jonathan
> -----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:
>
> - 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
>
>