Re: What is 802.3ae WAN-PHY?
Jonathan,
Nothing <- Answer to your last question.
On the mapping directly to SONET OAM&P bytes, we need to carefully consider this
issue. I'd rather look at this mapping at a slightly higher level. Mr. Roy Bynum
has already taken an excellent stab at this in a very recent note to this
reflector. I'll include My response to that note under a new thread: OAM&P
mapping.
Did our chair say "JUMBO frames". That's worse than a four-letter word :-)
Jonathan Thatcher wrote:
>
> 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
--
Best Regards,
Rich
-------------------------------------------------------
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